Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: transaction idle timeout in 7.4.5 and 8.0.0beta2
Date
Msg-id 5012.1095525785@sss.pgh.pa.us
Whole thread Raw
In response to Re: transaction idle timeout in 7.4.5 and 8.0.0beta2  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Responses Re: transaction idle timeout in 7.4.5 and 8.0.0beta2  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Re: transaction idle timeout in 7.4.5 and 8.0.0beta2  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
List pgsql-hackers
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> 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.

I don't see any reason for guesswork.  Remember the PID of the backend
you were connected to.  On reconnect, look in pg_stat_activity to see if
that backend is still alive; if so, sleep till it's not.  Then check to
see if your transaction committed or not.  No need for anything so
dangerous as a timeout.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Manfred Spraul
Date:
Subject: Re: tweaking MemSet() performance - 7.4.5
Next
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: transaction idle timeout in 7.4.5 and 8.0.0beta2