Thread: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.]

Hi PostgreSQL developers,

FYI, this was recently sent to the ancient old Debian bug report
'Postmaster ignores SIGPIPE'. [1] It seems that this was introduced
way back in 1997 in [2], but withouth a sufficient explanation why
SIGPIPE isn't properly handled instead of just ignored.

The bug trail in [1] contains a followup from Tom that ignoring
SIGPIPE is specifically intended. Is there any document which states
the reason for that?

Thanks in advance for any insight,

Martin

[1] http://bugs.debian.org/255208
[2] http://archives.postgresql.org/pgsql-hackers/1997-02/msg00276.php

----- Forwarded message from Markus Schaber <schabi@logix-tt.com> -----

Subject: Bug#255208: Would help with client aborts, too.
Reply-To: Markus Schaber <schabi@logix-tt.com>, 255208@bugs.debian.org
Date: Fri, 24 Mar 2006 13:08:55 +0100
From: Markus Schaber <schabi@logix-tt.com>
To: 255208@bugs.debian.org
X-Spam-Status: No, score=3D0.7 required=3D4.0 tests=3DAWL,BAYES_50,
    DATE_IN_FUTURE_06_12 autolearn=3Dno version=3D3.0.3

Hello,

Listening to SIGPIPE could also help detecting "unclean" client-side
connection aborts, e. G. due to a program crash or sigkill on the
client, or network problem between server and client.

This way, the server could abort long-running statements immediately,
instead of running them just to rollback them afterwards because the
client does not commit.

During development, I often forcedly abort my java clients, but the
server continues to execute the current statement. Having two or three
such sequential scans running in the background, selectively sending
SIGTERM to the backends as root is the only way to get the postmaster
responsive again.

Thanks,
Markus
--=20
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org



----- End forwarded message -----

--=20
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

Martin Pitt <martin@piware.de> writes:
> The bug trail in [1] contains a followup from Tom that ignoring
> SIGPIPE is specifically intended. Is there any document which states
> the reason for that?

Allowing SIGPIPE to kill the backend is completely infeasible, as the
backend would be unable to release locks etc before dying.

We have occasionally talked about faking a QueryCancel if we notice
a write failure while sending to the client.  Can't remember at the
moment what the outcome of those discussions was (ie, was there a
good reason not to) --- check the archives.

One point is that doing so doesn't help for queries that aren't
generating a lot of output, eg, updates/deletes.

            regards, tom lane

Tom Lane wrote:
> Allowing SIGPIPE to kill the backend is completely infeasible, as the
> backend would be unable to release locks etc before dying.

So the upshot is really not that ignoring SIGPIPE is specifically
intended as the optimal solution but that writing a proper cleanup
handler for SIGPIPE seems very difficult.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Allowing SIGPIPE to kill the backend is completely infeasible, as the
>> backend would be unable to release locks etc before dying.

> So the upshot is really not that ignoring SIGPIPE is specifically
> intended as the optimal solution but that writing a proper cleanup
> handler for SIGPIPE seems very difficult.

Well, if we did want to change this it would be far easier and safer to
do the other thing (ie, set QueryCancel upon noticing a write failure).

The question is whether doing either one is really a material
improvement, seeing that neither is going to provoke an abort
until/unless the backend actually tries to write something to the client.

            regards, tom lane

On Sun, Mar 26, 2006 at 08:34:46PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> Allowing SIGPIPE to kill the backend is completely infeasible, as the
> >> backend would be unable to release locks etc before dying.
>
> > So the upshot is really not that ignoring SIGPIPE is specifically
> > intended as the optimal solution but that writing a proper cleanup
> > handler for SIGPIPE seems very difficult.
>
> Well, if we did want to change this it would be far easier and safer to
> do the other thing (ie, set QueryCancel upon noticing a write failure).
>
> The question is whether doing either one is really a material
> improvement, seeing that neither is going to provoke an abort
> until/unless the backend actually tries to write something to the client.

Is there a server equivalent to PQstatus? If there were one, couldn't
the server periodically ping the client?
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

"Jim C. Nasby" <jnasby@pervasive.com> writes:
> On Sun, Mar 26, 2006 at 08:34:46PM -0500, Tom Lane wrote:
>> The question is whether doing either one is really a material
>> improvement, seeing that neither is going to provoke an abort
>> until/unless the backend actually tries to write something to the client.

> Is there a server equivalent to PQstatus? If there were one, couldn't
> the server periodically ping the client?

No, and do you really want the server stopping its processing of the
query just to go see if the client is still alive?  This would slow
things down and introduce a whole new failure mode, ie, client doesn't
answer ping fast enough so its session gets aborted.

(Just for the record, PQstatus isn't a "ping" operation either.)

            regards, tom lane

On Mon, Mar 27, 2006 at 09:50:38AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Sun, Mar 26, 2006 at 08:34:46PM -0500, Tom Lane wrote:
> >> The question is whether doing either one is really a material
> >> improvement, seeing that neither is going to provoke an abort
> >> until/unless the backend actually tries to write something to the client.
>
> > Is there a server equivalent to PQstatus? If there were one, couldn't
> > the server periodically ping the client?
>
> No, and do you really want the server stopping its processing of the
> query just to go see if the client is still alive?  This would slow
> things down and introduce a whole new failure mode, ie, client doesn't
> answer ping fast enough so its session gets aborted.

I guess it depends on how things are setup. Something like the following
probably wouldn't pose a tremendous amount of overhead...

set alarm 10 seconds;
bool ping_sent;
on alarm:
    if ping_sent then
        call to see if a ping reply is waiting for us (would this just
        sit in the network buffer, or would we actually get interrupted)
        if no ping then
            if timeout exceeded then
                abort backend;
            endif
        else
            set ping_sent = false;
        endif
    else
        ping_client();
        set ping_set = true;
    endif

Of course, the proof would be in doing some performance testing...
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461