Stmt timeout error can be sent after a CommandComplete
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t53078psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 01:55 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t53078_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t53078_1 && git checkout t53078_1Patchset v1 (message #1) is on t53078_1
Hi,
At the end of a command, disable_statement_timeout is called as the
timeout applies to a specific command and a CommandComplete message is
sent.
However, it's possible for the stmt timeout to have been fired between
the last message and the call to disable_statement_timeout. The
timeout won't be active anymore, so disable_timeout will be skipped.
However, the timeout is still queued, and the next call to
CHECK_FOR_INTERRUPTS will process and generate a stmt timeout error.
This leads to the confusing situation where we can have a
CompleteCommand message followed by a stmt timeout error for the same
command.
This patch fixes this issue by resetting the timeout indicator if the
timeout is inactive, relying on get_timeout_indicator to reset the
timeout indicator.
Regards,
Anthonin Bonnefoy
Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com> writes:
At the end of a command, disable_statement_timeout is called as the
timeout applies to a specific command and a CommandComplete message is
sent.
However, it's possible for the stmt timeout to have been fired between
the last message and the call to disable_statement_timeout. The
timeout won't be active anymore, so disable_timeout will be skipped.
However, the timeout is still queued, and the next call to
CHECK_FOR_INTERRUPTS will process and generate a stmt timeout error.
I think this overlaps the discussion we're having over here:
/messages/by-id/CAGECzQQD5f9ce-D1v6vCTT94hG=JbGdTHuf8vQ=HBLz9T4dA1g@mail.gmail.com
I agree that this area is a bit buggy, but I think it's got more
problems than just this.
regards, tom lane
On Tue, Jan 13, 2026 at 6:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I think this overlaps the discussion we're having over here:
/messages/by-id/CAGECzQQD5f9ce-D1v6vCTT94hG=JbGdTHuf8vQ=HBLz9T4dA1g@mail.gmail.com
I agree that this area is a bit buggy, but I think it's got more
problems than just this.
Yeah, that's definitely the same kind of issue. Thanks for the link, I
will catch up with the thread.