Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw |
Дата | |
Msg-id | CAA4eK1JNw0cqq4PGpMU1jszVRN9uWN=Xq-DYhTkWiJV1AgKAcw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
|
Список | pgsql-hackers |
On Tue, May 16, 2017 at 9:39 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, May 7, 2017 at 11:54 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> I'm having second thoughts based on some more experimentation I did >> this morning. I'll update again once I've had a bit more time to poke >> at it. > > So the issue that I noticed here is that this problem really isn't > confined to abort processing. If we ROLLBACK TO SAVEPOINT or ABORT > TRANSACTION on an open connection, we really do not know what the > state of that connection is until we get an acknowledgement that the > command completed successfully. The patch handles that. However, the > same is true if we're sending a SAVEPOINT or RELEASE SAVEPOINT > command, and the patch that I posted doesn't do anything about those > cases. I think it would be best to fix all transaction control > commands in a symmetric manner. > +1. Why not similar behavior for any other statements executed in this module by do_sql_command? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: