| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 | 
| Date: | 2004-09-18 20:05:26 | 
| Message-ID: | 7412.1095537926@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> On Sat, Sep 18, 2004 at 02:32:32PM -0400, Tom Lane wrote:
>> If there's a communications
>> problem, it might take awhile to detect connection loss ... but if
>> there's a communications problem, you probably aren't going to be able
>> to open a new connection, either.
> Unfortunately, a communications problem is exactly the kind of scenario
> we were talking about in the first place!  Might be a misguided firewall,
> for instance.  (In which case we'd want the TCP connection to time out
> quickly on the server as well to avoid piling up dead backends, but that's
> another matter).
Well, I think it would time out quickly --- anyway on the order of
minutes not hours.  By hypothesis, the situation you're worried about is
where the backend was unable to send you a COMMIT acknowledgement
message.  The kernel is going to realize that it didn't get an ACK back,
and is going to retry a few times, and is then going to declare the
connection lost.  The case where you may have a very long delay before
detection of connection loss is where the backend is sitting idle with
nothing to send.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oliver Jowett | 2004-09-18 20:09:35 | Re: libpq and prepared statements progress for 8.0 | 
| Previous Message | Jeroen T. Vermeulen | 2004-09-18 19:50:56 | Re: transaction idle timeout in 7.4.5 and 8.0.0beta2 |