Re: [HACKERS] psql and Control-C
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] psql and Control-C |
Дата | |
Msg-id | 27798.950850763@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql and Control-C (Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>) |
Ответы |
Re: [HACKERS] psql and Control-C
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: