Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw |
Дата | |
Msg-id | CA+TgmoaPV4tziUbddn8kRpPUhXCcWyak=oVmpvnx_7Dnh9cJbQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw
|
Список | pgsql-hackers |
On Thu, May 4, 2017 at 12:18 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > As soon as the first command fails due to timeout, we will set > 'abort_cleanup_failure' which will make a toplevel transaction to > abort and also won't allow other statements to execute. The patch is > trying to enforce a 30-second timeout after statement execution, so it > has to anyway wait till the command execution completes (irrespective > of whether the command succeeds or fail). I don't understand what you mean by this. If the command doesn't finish within 30 seconds, we *don't* wait for it to finish. To avoid getting inconsistent results in consequence, we set abort_cleanup_failure. > It is quite possible I am > missing some point, is it possible for you to tell in somewhat more > detail in which exact case 30-second timeout will allow us to abort > the toplevel transaction if we already do that in the case of > statement failure case? Suppose the user's original connection is stuck for some reason but the postmaster is still accepting new connections - e.g. somebody attached gdb to the remote server process and it is therefore stopped. The cancel request gets sent OK, but without the 30-second timeout, we'll hang forever (or until gdb continues or detaches the processes) waiting for it to take effect. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: