| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |
| Date: | 2015-02-03 20:17:22 |
| Message-ID: | 54D12CD2.2060100@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 02/03/2015 08:54 PM, Andres Freund wrote:
> * Previously the patchset didn't handle SIGTERM while
> InteractiveBackend() was reading from the client. It did handle
> ctrl-c/d, but since getc() isn't interruptible and can't be replaced
> with latches... The fix for that isn't super pretty:
> die():
> if (DoingCommandRead && whereToSendOutput != DestRemote)
> ProcessInterrupts();
> but imo acceptable for single user mode.
That smells an awful lot like ImmediateInterruptOK. Could you use
WaitLatchOrSocket to sleep on stdin? Probably needs to be renamed or
copied to WaitLatchOrStdin(), or a new flag to be added to wait on stdin
instead of a socket, at least on Windows, but in theory.
Might not be worth it if it gets complicated - I can live with the above
- but it's a thought.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-02-03 20:28:11 | Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |
| Previous Message | Andres Freund | 2015-02-03 18:54:10 | Re: Re: Overhauling our interrupt handling (was Escaping from blocked send() reprised.) |