| From: | surya poondla <suryapoondla4(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Subject: | Re: two statement_timeout race conditions |
| Date: | 2026-11-13 01:02:06 |
| Message-ID: | CAOVWO5qz9-tm7rRbkaerfXN5wkOiS6fZLULdV5uMP4eyXQzZ_A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Tomas,
Thank you for reporting the issue and the patch.
I tested v1 on master (0dbe240dc0e). Both reproducers show the problem on
master and are fixed with 0001+0002, make check and the isolation suite
pass.
+1 to Ayush's suggestion of also checking QueryCancelPending in
enable_statement_timeout(). 0001 resets the indicator in most cases, but an
Execute that ends in PortalSuspended doesn't go through
disable_statement_timeout(), so a stale indicator could still reach the
next statement in the same pipeline (before Sync). For example, a CALL with
an INOUT parameter that does COMMIT, executed with max_rows = 1, where
statement_timeout fires during the sync rep wait (which clears
QueryCancelPending but not the indicator). It's a narrow case, and the
extra check seems cheap.
Regards,
Surya Poondla
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ritesh Kumar | 2026-11-13 01:04:28 | Re: [Patch] Batch fsyncs when recycling WAL segments |
| Previous Message | Fujii Masao | 2026-11-13 00:59:59 | Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting |