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

> 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:

Reply via email to