On Sun, Oct 16, 2005 at 04:06:04PM -0400, Andrew Dunstan wrote:
> Martin,
>
> Let's see the patch. I assume it should be fairly small. If we could get
> it in early in the 8.2 cycle we would have plenty of time to bang on it.
> In principle this sounds reasonable to me, but psql can be broken quite
> easily - I know as I've done it a couple of times ;-)
Very well, patch attached. It's quite simple actually. However, there
seems to be some push back from people suggesting that jumping back to
the main loop before the pager has quit is not buggy behaviour.
Assuming that a ^C will kill the pager is just folly.
Tom asked if we should be blocking SIGQUIT and SIGHUP too. Standard
procedure for spawning external interactive processes includes blocking
SIGQUIT too (see system() manpage). Logically speaking, when the user
sends an interrupt from the keyboard they expect to interrupt the
currently active *interaxtive* process. Hence, once psql has spawned
the pager, it should ignore such interrupts until control is returned
(after pclose). So yes, I would suggest blocking SIGQUIT also, if only
to prevent terminal corruption problems. Interactive programs like less
trap SIGQUIT to restore the terminal settings on exit, but the exit
anyway.
SIGHUP is different. It is sent by the system, not the user, indicating
the terminal has disconnected. psql is not a daemon expecting to
survive that and hence should quit as normal, along with all other
processes on that terminal.
If this isn't going to make 8.1 anyway I'd probably go for a patch that
got rid of the longjmp altogether (if people will accept that), fixing
the memory leaks at the same time. At the moment I'm just looking for a
concensus that it's a problem to be solved.
Have a nice day,
--
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.