PQinSend question - Mailing list pgsql-hackers

From Manfred Spraul
Subject PQinSend question
Date
Msg-id 40016D0A.9030906@colorfullife.com
Whole thread Raw
Responses Re: PQinSend question  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PQinSend question  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
 From fe-secure.c:

> /*
>  *      Indicates whether the current thread is in send()
>  *      For use by SIGPIPE signal handlers;  they should
>  *      ignore SIGPIPE when libpq is in send().  This means
>  *      that the backend has died unexpectedly.
>  */
> pqbool
> PQinSend(void)
> {
> #ifdef ENABLE_THREAD_SAFETY
>         return (pthread_getspecific(thread_in_send) /* has it been 
> set? */ &&
>                         *(char *)pthread_getspecific(thread_in_send) 
> == 't') ? true : false;
> #else
>         return false;   /* No threading, so we can't be in send() */

Why not? Signal delivery can interrupt send() even with single-threaded 
users.

I really like the openssl interface: what about something like

typedef void (*pgsigpipehandler_t)(bool enable);

void PQregisterSignalCallback(pgsigpipehandler_t new);

The callback is global, and called around the send() calls.
The default handler uses the sigaction code from 7.4. The current 
autodetection code is less flexible than a callback, and it's not 100% 
backward compatible.

--   Manfred



pgsql-hackers by date:

Previous
From: Manfred Spraul
Date:
Subject: libpq thread safety
Next
From: "Mark Cave-Ayland"
Date:
Subject: Suggestions for analyze patch required...