Re: Idle transaction cancel/timeout and SSL revisited
От | Andres Freund |
---|---|
Тема | Re: Idle transaction cancel/timeout and SSL revisited |
Дата | |
Msg-id | 20141114213537.GD13995@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Idle transaction cancel/timeout and SSL revisited (Alex Shulgin <ash@commandprompt.com>) |
Ответы |
Re: Idle transaction cancel/timeout and SSL revisited
Re: Idle transaction cancel/timeout and SSL revisited |
Список | pgsql-hackers |
Hi, 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: