Lists: | pgsql-hackers |
---|
From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | PQinSend question |
Date: | 2004-01-11 15:34:34 |
Message-ID: | 40016D0A.9030906@colorfullife.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | 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
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQinSend question |
Date: | 2004-01-11 17:28:53 |
Message-ID: | 17056.1073842133@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Manfred Spraul <manfred(at)colorfullife(dot)com> 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 handler during every send().
So there's no need for PQinSend() to do anything useful.
regards, tom lane
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQinSend question |
Date: | 2004-02-10 15:20:59 |
Message-ID: | 200402101520.i1AFKxb20064@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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.
> > */
> > 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.
[ Sorry I am late replying to this.]
I have added the attached comment to CVS to more clearly describe why we
are returning false from PQinSend().
> 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.
I think I addressed this and it is backward compatible (thread-local
storage), and requires no user application changes.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 1000 bytes |
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Manfred Spraul <manfred(at)colorfullife(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PQinSend question |
Date: | 2004-02-10 15:21:42 |
Message-ID: | 200402101521.i1AFLg520255@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Manfred Spraul <manfred(at)colorfullife(dot)com> 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 handler during every send().
> So there's no need for PQinSend() to do anything useful.
I have updated the CVS comments to more clearly explain this.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073