Re: statement_timeout vs DECLARE CURSOR

I wrote:
> Christophe Pettus <xof@thebuild.com> writes:
>> A bit more poking revealed the reason: The ON HOLD cursor's query is executed at commit time (which is, logically,
notinterruptible), but that's all wrapped in the single statement outside of a transaction. 

> Hmm ... seems like a bit of a UX failure.  I wonder why we don't persist
> such cursors before we get into the uninterruptible part of COMMIT.

Oh, I see the issue.  It's not that that part of COMMIT isn't
interruptible; you can control-C out of it just fine.  The problem
is that finish_xact_command() disarms the statement timeout before
starting CommitTransactionCommand at all.

We could imagine pushing the responsibility for that down into
xact.c, allowing it to happen after CommitTransaction has finished
running user-defined code.  But it seems like a bit of a mess
because there are so many other code paths there.  Not sure how
to avoid future bugs-of-omission.

            regards, tom lane