Re: statement_timeout vs DECLARE CURSOR

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christophe Pettus <xof(at)thebuild(dot)com>
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: statement_timeout vs DECLARE CURSOR
Date: 2021-09-28 19:57:21
Message-ID: 2873020.1632859041@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

I wrote:
> Christophe Pettus <xof(at)thebuild(dot)com> writes:
>> A bit more poking revealed the reason: The ON HOLD cursor's query is executed at commit time (which is, logically, not interruptible), 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2021-09-28 20:15:14 Re: statement_timeout vs DECLARE CURSOR
Previous Message Jeff Hoffmann 2021-09-28 19:35:06 Re: Problem with identity column & related sequences

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-09-28 20:15:14 Re: statement_timeout vs DECLARE CURSOR
Previous Message Antonin Houska 2021-09-28 19:19:41 Re: POC: Cleaning up orphaned files using undo logs