[elephant-devel] Re: Postmodern regression

[Alex Mizrahi]

 ??>> but are you sure that restarting txn in this case is right, and when
 ??>> such stuff happens at all?

 LPP> Heh, if you ask me the best solution would be if Postgres
 LPP> just shut up about it without affecting the txn.
 LPP> But alas, this isn't the case.

hmm, postgres documentation says:
----
Prepared statements only last for the duration of the current database 
session. When the session ends, the prepared statement is forgotten, so it 
must be recreated before being used again. This also means that a single 
prepared statement cannot be used by multiple simultaneous database clients; 
however, each client can create their own prepared statement to use.
----

it's pretty strange that we got such problem with per-session object -- they 
are not shared across sessions, so we should get no concurrent conflicts. 
perhaps there's a bug somewhere, like doing initialization twice.

also, it's not clear what happens if transaction is rolled back -- is 
prepared statement rolled back too, or it is memorized?
it seems this way our idea of memorized statements and db session can be 
desynchronized, but actually in _oposite direction_: our code will think 
that it's there, but it is not.

maybe it somehow bleeds from other connections?

i think that instead of blindly retrying txn we should find cause of this 
problem

 LPP> I have also tried deallocating the statement in question

why do you want to deallocate it -- you think old one is bad? :)
if it's there but we don't know about it, we can just mark statement as 
prepared so further call won't try to prepare it.

 LPP> before invoking the restart but it seems that any execution of
 LPP> SQL at this time will hang indefinitely.
 LPP> Do you have any idea why this would happen?

never seen postgres hanging. if txn is aborted, it just ignores all 
sebsequent statements. but is should not hang..