From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | Szima G?bor <sygma(at)axelero(dot)hu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
Date: | 2004-09-18 16:43:05 |
Message-ID: | 5012.1095525785@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen T. Vermeulen | 2004-09-18 16:49:47 | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |
Previous Message | Manfred Spraul | 2004-09-18 15:38:36 | Re: tweaking MemSet() performance - 7.4.5 |