| 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>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: SIGPIPE handling, take two. |
| Date: | 2003-11-11 18:22:04 |
| Message-ID: | 11953.1068574924@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> ... But the SIG_IGN/restore
> sequence affects the whole app - PQconnectdb calls would result in
> randomly dropped SIGPIPE signals.
Good point. AFAICS we lose anyway if we don't have sigaction()
available, but hopefully any multithreaded platform has sigaction().
I still don't like modifying pqsignal's API though. What I suggest
is adding a function like "pqsignalinquire(signalno)" to pqsignal.c,
defined to return the signal handler without changing it ... that is,
take the system-dependent code you were going to put in fe-connect.c
and put it in pqsignal.c instead.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-11-11 20:52:25 | Re: psql: \dg and groups for \du |
| Previous Message | Manfred Spraul | 2003-11-11 17:37:52 | Re: SIGPIPE handling, take two. |