Re: zombie connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: zombie connections
Date: 2020-04-03 14:34:37
Message-ID: 23937.1585924477@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I prefer simple solution without any "intelligence". It is much safer to
> close connect and rollback. Then it is clean protocol - when server didn't
> reported successful end of operation, then operation was reverted - always.

It would be a fatal mistake to imagine that this feature would offer any
greater guarantees in that line than we have today (which is to say,
none really). It can be no better than the OS network stack's error
detection/reporting, which is necessarily pretty weak. The fact that
the kernel accepted a "command complete" message from us doesn't mean
that the client was still alive at that instant, much less that the
message will be deliverable.

In general I think the threshold problem for a patch like this will be
"how do you keep the added overhead down". As Robert noted upthread,
timeout.c is quite a bit shy of being able to handle timeouts that
persist across statements. I don't think that there's any fundamental
reason it can't be improved, but it will need improvements.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2020-04-03 14:43:17 Re: adding partitioned tables to publications
Previous Message Alexey Kondratov 2020-04-03 14:29:45 Re: [HACKERS] make async slave to wait for lsn to be replayed