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

Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: markw(at)osdl(dot)org, pgsql-hackers(at)postgresql(dot)org,osdldbt-general(at)lists(dot)sourceforge(dot)net
Subject: Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
Date: 2003-11-04 19:33:52
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> For multithreaded apps, this is not possible: sigaction is per process.
> Thus the calling application must handle the SIGPIPE signals for libpq - 
> either by blocking or ignoring them. We are still discussing the exact 
> API. Probably a global state that is accessible through a new function.

I think we should also take a hard look at avoiding the problem by using
MSG_NOSIGNAL on platforms that have it, so that the right things happen
and overhead is minimized whether or not the application knows to do
this.  Besides I am not convinced that an app that *wants* SIGPIPE on
some of its output channels could reasonably solve the problem with a
custom signal handler --- how will the handler know which FD the signal
came from?

The difficulty with MSG_NOSIGNAL is in getting libssl to cooperate.
I wonder if we could convince the libssl implementors that MSG_NOSIGNAL
should be used when available in their standard release, or at least
they should provide an option to use it?  The alternative would be to
create our own BIO for libssl, which I think is doable, but would likely
be a pain in the neck to maintain.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-11-04 19:44:02
Subject: Re: Open Sourcing pgManage
Previous:From: kgleasonDate: 2003-11-04 19:32:24
Subject: Re: Hacking PostgreSQL to work in Mac OS X 10.3 (Panther 7B85)

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