----- Original Message -----
From: "Jeroen T. Vermeulen" <[EMAIL PROTECTED]>
> I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels
> this February) for libpqxx. My code tries to compensate for the
> possibility that the backend connection is lost while waiting for a reply
> to a COMMIT. The way I worked around it was to create a special record
> at the beginning of the transaction, in a dedicated table that's
> effectively a custom transaction log. If the record is still there when
> I reconnect, the transaction committed. If not, it didn't.
>
> Obviously this leaves some garbage collection issues, so I'd be really
> happy with a way to go back to the server after my connection is lost
> and find out whether my transaction committed or not.
I see a race condition in this approach: if you reconnect too fast, and the
backend which actually should commit is still in progress (assume it takes a
while to commit for whatever reasons) you get the impression that it did not
commit - and a short time later the backend will commit... (before noticing
that the client connection was lost).
A safe method would be to shut down all backends (or is there another method
to safely abort all transactions?), then start the backends again, and then
read the table with the special records. In this way you would be sure that
your transaction is not in progress while you're inspecting the table.
Ofcourse, this approach is not very fast and may abort alot of
transactions - but if consistency is more important for you than anything
else...
- Christian
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
