Jeremy Kerr writes:
>> MSG_NOSIGNAL is a recv() flag, no?
> It's a flag to send().
Doh, need more caffeine.
>> 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.
> Yep, a once-off test
On 6/2/09, Tom Lane wrote:
> Marko Kreen writes:
> > On 6/2/09, Tom Lane 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
Tom,
> 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?
It's a flag to send().
> The question is whether you could expect that the recv() would fail if
>
Marko Kreen writes:
> On 6/2/09, Tom Lane 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 insta
On 6/2/09, Tom Lane wrote:
> Jeremy Kerr writes:
>
> >> The consideration is that the application fails completely on server
> >> disconnect (because it gets SIGPIPE'd). This was long ago deemed
> >> unacceptable, and we aren't likely to change our opinion on that.
>
> > OK, understood. I'm g
Jeremy Kerr writes:
>> The consideration is that the application fails completely on server
>> disconnect (because it gets SIGPIPE'd). This was long ago deemed
>> unacceptable, and we aren't likely to change our opinion on that.
> OK, understood. I'm guessing MSG_NOSIGNAL on the send() isn't por
On 6/2/09, Tom Lane wrote:
> Jeremy Kerr writes:
> > The following patch changes psecure_write to be more like psecure_read -
> > it only alters the signal mask if the connection is over SSL. It's only
> > an RFC, as I'm not entirely sure about the reasoning behind blocking
> > SIGPIPE for th
Tom,
> The consideration is that the application fails completely on server
> disconnect (because it gets SIGPIPE'd). This was long ago deemed
> unacceptable, and we aren't likely to change our opinion on that.
OK, understood. I'm guessing MSG_NOSIGNAL on the send() isn't portable
enough here?
Jeremy Kerr writes:
> The following patch changes psecure_write to be more like psecure_read -
> it only alters the signal mask if the connection is over SSL. It's only
> an RFC, as I'm not entirely sure about the reasoning behind blocking
> SIGPIPE for the non-SSL case - there may be other consid
Currently, I'm seeing the psecure_{red,write} functions being invoked
when connecting to postgres via a unix domain socket. psecure_write
seems to alter the signal mask of the process to disable sigpipe
reporting. psecure_read only does this when the connection is using SSL.
When using a multithre
10 matches
Mail list logo
