Re: [RFC,PATCH] SIGPIPE masking in local socket connections - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC,PATCH] SIGPIPE masking in local socket connections
Date
Msg-id 11613.1243952642@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC,PATCH] SIGPIPE masking in local socket connections  (Marko Kreen <markokr@gmail.com>)
Responses Re: [RFC,PATCH] SIGPIPE masking in local socket connections  (Jeremy Kerr <jk@ozlabs.org>)
Re: [RFC,PATCH] SIGPIPE masking in local socket connections  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
Marko Kreen <markokr@gmail.com> writes:
> On 6/2/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We've had problems before with userland headers not being in sync
>> with what the kernel knows.

> Well, we could just test in configure perhaps?

The single most common way to get into that kind of trouble is to
compile on machine A then install the executables on machine B with
a different kernel.  So a configure test wouldn't give me any warm
feeling at all.

A feature that is exercised via setsockopt is probably fairly safe,
since you can check for failure of the setsockopt call and then do
it the old way.  MSG_NOSIGNAL is a recv() flag, no?  The question
is whether you could expect that the recv() would fail if it had
any unrecognized flags.  Not sure if I trust that.  SO_NOSIGPIPE
seems safer.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: [RFC,PATCH] SIGPIPE masking in local socket connections
Next
From: "Markus Wanner"
Date:
Subject: Re: PostgreSQL Developer meeting minutes up