On Sun, Jun 11, 2006 at 02:08:12PM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Sun, Jun 11, 2006 at 12:32:22PM -0400, Tom Lane wrote:
> >> I think we should try very hard to get rid of the longjmp in the signal
> >> handler altogether.
>
> > I submitted a patch for this ages ago and AFAIK it's still in the
> > queue. Have you any issues with the way I did it there?
>
> If you're speaking of
> http://archives.postgresql.org/pgsql-patches/2005-10/msg00194.php
> it doesn't appear to me to remove longjmp from the signal handler.
> Was there a later version?
As it states in the comment, you can't remove the longjump because
it's the only way to break out of the read() call when using BSD signal
semantics (unless you're proposing non-blocking read+select()). So the
patch sets up the sigjump just before the read() and allows the routine
to return. If you're not waiting for read(), no sigjump is done.
Note, this problem affects all read/writes using psql. With the patch,
if any read/write other than that particular one blocks, the signal
handler won't be able to break out. The infrastructure is there to
handle other reads, but if you block inside libpq, you're SOL.
I'm open to alternative suggestions for how to deal with this. I
imagine switching to SysV signal semantics is out of the question...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
