Re: transaction idle timeout in 7.4.5 and 8.0.0beta2

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: Szima G?bor <sygma(at)axelero(dot)hu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: transaction idle timeout in 7.4.5 and 8.0.0beta2
Date: 2004-09-18 15:19:01
Message-ID: 20040918151901.GA59219@xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manfred Spraul 2004-09-18 15:38:36 Re: tweaking MemSet() performance - 7.4.5
Previous Message Tom Lane 2004-09-18 15:13:18 Re: Interesting issue with SFR in PL/pgSQL ...