| From: | Marko Kreen <markokr(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Jeremy Kerr <jk(at)ozlabs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [RFC,PATCH] SIGPIPE masking in local socket connections |
| Date: | 2009-06-02 13:53:08 |
| Message-ID: | e51f66da0906020653w70a21cf9h19f41b32af7ee48c@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/2/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jeremy Kerr <jk(at)ozlabs(dot)org> 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 considerations here.
>
>
> 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.
>
> What disturbs me about your report is the suggestion that there are
> paths through that code that fail to protect against SIGPIPE. If so,
> we need to fix that.
Slightly OT, but why are we not using MSG_NOSIGNAL / SO_NOSIGPIPE
on OS'es that support them? I guess significant portion of userbase
has at least one of them available...
Thus avoiding 2 syscalls per operation plus potential locking issues.
--
marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aidan Van Dyk | 2009-06-02 13:54:37 | Re: PostgreSQL Developer meeting minutes up |
| Previous Message | Jeremy Kerr | 2009-06-02 13:52:01 | Re: [RFC,PATCH] SIGPIPE masking in local socket connections |