Manfred Spraul wrote:
> 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.
> > */
Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
> >> return false; /* No threading, so we can't be in send() */
>
> > Why not? Signal delivery can interrupt send() even with single-threaded
> > users.
>
> It looks like Bruce left the old logic in place for unthreaded
> implementat
Manfred Spraul <[EMAIL PROTECTED]> writes:
>> return false; /* No threading, so we can't be in send() */
> Why not? Signal delivery can interrupt send() even with single-threaded
> users.
It looks like Bruce left the old logic in place for unthreaded
implementations: we just replace the signal
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_SAFET
