Skip site navigation (1) Skip section navigation (2)

Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL

From: AgentM <agentm(at)webopticon(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL
Date: 2003-11-02 20:32:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sunday, Nov 2, 2003, at 18:16 Europe/Berlin, Tom Lane wrote:
> Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
>> Tom Lane wrote:
>>> I don't see that this proposal adds any security.
>> It's not about security:
> The proposal would be more salable if it addressed the security problem
> too.  As is, you are proposing putting a large wart on libpq's API in
> order to work around an inefficiency that's only been shown to exist in
> one version of one operating system.  I'd like to look for other
> solutions before we do that.
> One possibility that comes to mind is simply to test whether the 
> handler is already SIG_IGN before we munge it.  Ideally we'd do that
> once when the conn object is created, but even if it had to be done 
> more
> often, it might still be a net win.

That wouldn't offer a solution for people who use SIGPIPE for other 
things during the lifetime of the program (after creating the 
connection) and if a SIGPIPE handler is called due to the connection, 
the handler won't be expecting the source, and polling signal for state 
is essentially what you do now. Instead, I propose a 
PQsigpipeOK/PQacceptsigpipe/PQrecvsigpipe(PGconn*) or something to that 
effect which skips this check for the connection. That way, programmers 
are aware that the connection could call their SIGPIPE handler because 
they explicitly request it and the library remains backwards-compatible.

In response to


pgsql-hackers by date

Next:From: Manfred SpraulDate: 2003-11-02 21:10:57
Subject: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL
Previous:From: Tom LaneDate: 2003-11-02 18:00:35
Subject: Re: Experimental patch for inter-page delay in VACUUM

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group