Re: Idle In Transaction Session Timeout, revived
От | Andres Freund |
---|---|
Тема | Re: Idle In Transaction Session Timeout, revived |
Дата | |
Msg-id | 20160308230819.6kx4ihcjyq6u3es5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Idle In Transaction Session Timeout, revived (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Idle In Transaction Session Timeout, revived
|
Список | pgsql-hackers |
On 2016-03-08 16:42:37 -0500, Robert Haas wrote: > - I really wonder if the decision to ignore sessions that are idle in > transaction (aborted) should revisited. Consider this: > > rhaas=# begin; > BEGIN > rhaas=# lock table pg_class; > LOCK TABLE > rhaas=# savepoint a; > SAVEPOINT > rhaas=# select 1/0; > ERROR: division by zero Probably only if the toplevel transaction is also aborted. Might not be entirely trivial to determine. > - What's the right order of events in PostgresMain? Right now the > patch disables the timeout after checking for interrupts and clearing > DoingCommandRead, but maybe it would be better to disable the timeout > first, so that we can't have it happen that start to execute the > command and then, in medias res, bomb out because of the idle timeout. > Then again, maybe you had some compelling reason for doing it this > way, in which case we should document that in the comments. Hm, we should never bomb out of the middle of anything with this, right? I mean all the itmeout handler does is set a volatile var and set a latch, the rest is done in the interrupt handler? Which is not called in the signal handler. I'm no targuing for the current order, just that one argument ;). FWIW, I think Vik wrote this after discussing with me, and IIRC there was not a lot of reasoning going into the specific location for doing this. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: