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
