On Thu, May 4, 2017 at 12:18 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
