On Tue, Oct 18, 2005 at 09:32:25PM -0700, Kevin Brown wrote:
> So I think the right answer here is for psql to handle SIGINT
> internally by doing a pclose() first (and at this point, it probably
> should ignore SIGINT altogether), then returning to the main loop
> (and, of course, cleaning up anything that needs it along the way).
> If the child hasn't exited then pclose() will block until it has. The
> end result should be the semantics you want: if psql is in the middle
> of sending a bunch of rows of output to the pager, this will interrupt
> that process. If the pager remains running then it will hopefully
> give the user the ability to scroll through whatever results were sent
> to it.
That's what I meant by "more comprehensive patch". Basically, the
longjmp has to go because it leaks memory (and file descriptors) and
doesn't allow you to control things at the right level. My little patch
basically set the signal handler *after* the popen so everything works
as expected.
My plan is to have the interrupt handler set a flag "control_c_pressed"
and check it at strategic points. Then memory can be deallocated and
returned properly. It's a lot more invasive and the corners cases will
be "interesting".
Your point about SIGQUIT is valid. I didn't include it in my patch
since I wasn't sure what the expected behaviour would be. If I got core
files everytime I pressed SIGQUIT, I'd have a lot of core files
scattered around my disk; one of the reasons I disable core files by
default.
OTOH, if I wanted to trap psql, I'd run it under a debugger or attach
one which would catch SIGQUIT even if the program ignores it.
Anyway, thanks for the response, hopefully we can get this sorted out
in a later release...
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.