From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Alex Shulgin <ash(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Idle transaction cancel/timeout and SSL revisited |
Date: | 2014-11-14 21:35:37 |
Message-ID: | 20141114213537.GD13995@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Shulgin | 2014-11-14 21:46:37 | Re: Idle transaction cancel/timeout and SSL revisited |
Previous Message | Alex Shulgin | 2014-11-14 21:11:36 | Idle transaction cancel/timeout and SSL revisited |