Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
> Alfred Perlstein wrote:
>> Whoa whoa... It's a bit more complicated than you think, there's a lot
>> of state that gets put into libpq,
> I don't think this has anything to do with libpq. This has got to do
> with psql's reading of commands _before_ they get shoved into
> libpq. As such it shouldn't be that dangerous.
Chris is right that this is not a libpq issue. psql would be set up
so that the signal-catching routine either issues a cancel request
(if a query is in progress) or attempts a longjmp (if not). If
properly implemented, there is zero chance of screwing up libpq.
However, there is some chance of screwing up libreadline --- I don't
know enough about its innards to know if it can survive losing
control at a random point. If we can confine the region where longjmp
will be attempted to just the point where the program is blocked
waiting for user input, it'd probably be pretty safe.
Something I've noticed that might or might not be related to this
issue is that if psql exits due to backend crash, it fails to save the
last few lines of command history into the history file. Not closing
down libreadline, maybe?
regards, tom lane