Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL internals if we try to longjump out of the
>> signal handler in the middle of a blocking SSL read and/or if we try to
>> report that final "transaction/connection aborted" notice to the client.
>
> I've written a patch that allows that - check
> http://archives.postgresql.org/message-id/20140927225421.GE5423%40alap3.anarazel.de
>
> I feel pretty confident that that's the way to go. I just need some time
> to polish it.
>
>> What if instead of trying to escape from the signal handler we would set
>> a flag and use it to simulate EOF after the recv() is restarted due to
>> EINTR? From the backend perspective it should look like the client has
>> just hang up.
>
> That's pretty much what the above does. Except that it actually deals
> with blocking syscalls by not using them and relying on latches/select
> instead.
Yay, that's nice, because my EOF approach is sort of fishy.
I've checked the patches: they apply and compile on top of current HEAD
(one failed hunk in pqcomm.c), so I can help with testing if needed.
There is a (short) list of items that caught my attention. I will post
in reply to your patches thread.
--
Alex
