Re: two statement_timeout race conditions

On Sat, 14 Nov 2026, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> You mean the "statement timeout" reported as "user request"? I believe
> that happens because the timeout indicator is cleared, while the
> QueryCancelPending is left set. But here we're resetting both, so I
> don't see how could it have the same effect.
>
> What's the scenario that'd lead to the same issue?

With synchronous_standby_names=nobody and max_prepared_transactions=5:

SET synchronous_commit = local;
CREATE TABLE s (x int);
CREATE PROCEDURE p_commit() LANGUAGE plpgsql AS $$
BEGIN
INSERT INTO s VALUES (1);
COMMIT;
RAISE NOTICE 'after commit, indicator consumed by syncrep';
END $$;

SET synchronous_commit = on;
SET statement_timeout = '200ms';
CALL p_commit();
-- SET
-- SET
-- WARNING: canceling wait for synchronous replication due to user request
-- DETAIL: The transaction has already committed locally, but might
not have been replicated to the standby.
-- NOTICE: after commit, indicator consumed by syncrep
-- CALL

And also:

SET statement_timeout = 0;
SET synchronous_commit = local;
BEGIN; INSERT INTO s VALUES (2); PREPARE TRANSACTION 'g1';
SET synchronous_commit = on;
SET statement_timeout = '200ms';
COMMIT PREPARED 'g1';
-- same due to user request message