??>> 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.. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
