On Fri, Sep 17, 2004 at 08:47:02AM +0200, Szima G?bor wrote:
> I was implement the "transaction idle timeout" function in PostgreSQL
> (version 7.4.5 and 8.0.0beta2)
It sounds interesting to me (for use in libpqxx, the C++ API), but perhaps
for a slightly unusual reason. When a connection to the backend is lost
just as you're waiting for the result of a COMMIT, you can't be sure if the
transaction was rolled back or not.
If I could know (not influence, just "know") when a transaction times out,
then I could wait for this amount of time, reconnect to the backend, and
check for some record left in a special table by the transaction. If it's
not there, I'll know "for sure" (insofar as anything can ever be sure) that
the transaction was not committed. This is still guesswork in the current
situation.
There's one assumption, however, and that is that the transaction will time
out even if (part of) the timeout time was spent processing rather than
waiting for a command. I'm not sure how many people would be willing to
pay that price. Perhaps a connection timeout would be more appropriate for
this sort of thing.
Jeroen