From: Tom Lane <tgl@sss.pgh.pa.us>
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Stmt timeout error can be sent after a CommandComplete
In-reply-to: <CAO6_Xqqq2UAeRxrjxN9htu4RtvxJEWw4rLha4mPe5FOoZ2Byug@mail.gmail.com>
References: <CAO6_Xqqq2UAeRxrjxN9htu4RtvxJEWw4rLha4mPe5FOoZ2Byug@mail.gmail.com>
Comments: In-reply-to Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
	message dated "Tue, 13 Jan 2026 10:20:32 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4182251.1768325454.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Jan 2026 12:30:54 -0500
Message-ID: <4182252.1768325454@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/4182252.1768325454%40sss.pgh.pa.us>
Precedence: bulk

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:

https://www.postgresql.org/message-id/flat/CAGECzQQD5f9ce-D1v6vCTT94hG%3DJ=
bGdTHuf8vQ%3DHBLz9T4dA1g%40mail.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