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

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

From: Manfred Spraul <manfred(at)colorfullife(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-01 18:27:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:

>Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
>>Is that really necessary?
>Unfortunately, yes.  libpq can't change the global setting of SIGPIPE
>without breaking the surrounding application, but we don't want to crash
>the app if the server connection has disappeared, either.  So we have to
>set the SIGPIPE handler and then restore it around every send().
Ok. Ahm. No, wait. libpq is multi-threaded, right?

signal handlers are a process property, not a thread property - that 
code is broken for multi-threaded apps.
At least that's how I understand the opengroup man page, and a quick 
google confirmed that:

I haven't found a reliable thread-safe approach yet:
My first idea was block with pthread_sigmask, after send check if 
pending with sigpending, and then delete with sigwait, and restore 
blocked state. But that breaks if SIGPIPE is blocked and a signal is 
already pending: there is no way to remove our additional SIGPIPE. I 
don't see how we can avoid destroying the realtime signal info.

Mark: Is your dbt2 testapp multithreaded? I don't see the signal 
functions near the top in the profiles on the osdl website.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2003-11-01 18:37:30
Subject: Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
Previous:From: Peter EisentrautDate: 2003-11-01 18:21:08
Subject: Re: Proposal: psql force prompting on notty

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