Re: two statement_timeout race conditions

Hello!

I tested this patch a bit, and claude pointed out another corner case:
lock_timeout firing during COMMIT still leaks into the next command

finish_xact_command() runs the new discard before the commit:

/* cancel active statement timeout after each command */
disable_statement_timeout();

if (xact_started)
{
CommitTransactionCommand();

But commit can still wait for a heavyweight lock: PreCommit_Notify()
takes the "database 0" lock, and there's no CHECK_FOR_INTERRUPTS()
after the grant until the end of the commit. If lock_timeout fires
just as that lock is granted, the COMMIT succeeds and the next command
fails. Tiny window, so it needs an additional sleep to be reliably
reproducible.

The same happens with an extended protocol autocommit SELECT
pg_notify(...) (committed at Sync) followed by any statement, and with
a pipelined statement after COMMIT.

This seems to fix it:

@@ finish_xact_command
CommitTransactionCommand();

+ /*
+ * Commit itself can wait for a heavyweight lock (PreCommit_Notify),
+ * after disable_statement_timeout() above already ran. Discard a
+ * lock timeout request left behind by a grant at timeout time.
+ */
+ if (get_timeout_indicator(LOCK_TIMEOUT, true))
+ QueryCancelPending = false;

And in 0002:

QueryCancelPending = false;
+ (void) get_timeout_indicator(LOCK_TIMEOUT, true);
+ (void) get_timeout_indicator(STATEMENT_TIMEOUT, true);
ereport(WARNING,
(errmsg("canceling wait for synchronous replication due to user request"),

Won't this result in the same incorrect message pattern the patch
tries to repair elsewhere?