Re: [HACKERS] psql and Control-C

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: chris(at)bitmead(dot)com
Cc: PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] psql and Control-C
Date: 2000-02-18 05:12:43
Message-ID: 27798.950850763@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-02-18 05:16:48 Re: [HACKERS] Almost there on column aliases
Previous Message Chris Bitmead 2000-02-18 05:09:29 Re: [HACKERS] psql and Control-C