Idle transaction cancel/timeout and SSL revisited
Hello Hackers,
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.
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.
Both SSL and cleartext connections are routed through secure_raw_read,
so it seems like a good candidate for checking the flag we would set in
StatementCancelHandler(). (Should we also add the same check in
interactive_getc()?)
Ultimately, in PostgresMain() the ReadCommand() would return EOF and we
can either let the existing code shutdown the backend, or add special
handling that will only abort the transaction and report the case to the
client, which was the intent in[1]/messages/by-id/1262268211.19367.10736.camel@ebony. And if that works out, the timeout
handler in[2]/messages/by-id/538DC843.2070608@dalibo.com can simply reuse the flag.
A potential problem with this is that SSL might perform some eager
cleanup when seeing EOF, so the backend might need to reset/restart the
connection (is that possible?)
I'm attaching a patch (that doesn't compile yet :-p) in hope it can be
useful for the purpose of the discussion. Notably, secure_raw_read()
can't know about IdleTransactionCancelPending and I'm not sure what
would be the best way to let it see that (is it too much of a shortcut
anyway?)
--
Alex
[1]: /messages/by-id/1262268211.19367.10736.camel@ebony
[2]: /messages/by-id/538DC843.2070608@dalibo.com
Attachments:
cancel_idle_xact.v1.patchtext/x-diffDownload+56-41
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.deI 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
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.deI 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers