Andres Freund <and...@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.
Neat, I must have missed it. -- Alex -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
