Skip to content

test: the pooler soak's clients survive a chaos cancel that lands outside pg_warren - #138

Merged
wfaithfull merged 1 commit into
mainfrom
fix-soak-cancel-race
Oct 29, 2026
Merged

wfaithfull merged 1 commit into
mainfrom
fix-soak-cancel-race

Conversation

@wfaithfull

Copy link
Copy Markdown
Contributor

Fixes a race in the pooler soak's chaos that failed Generators + SQL harness (PG 16) on #125 (SET statement_timeout = '120s': canceling statement due to user request).

Chaos reads pg_stat_activity for a pooled backend running a warren. call, then calls pg_cancel_backend. Under transaction pooling the call can finish in between and the cancel lands on the next client's statement on that backend. One statement can't close that gap, so the clients now tolerate the stray cancel where it is harmless:

  • test/harness/session.py: setup statements (SETs, pg_backend_pid()) cancelled by request (57014, "due to user request", not a timeout) run again, up to 5 times, counted in Session.canceled_setup; any other failure still raises.
  • test/harness/pooler_soak/workload.py: those, and a cancelled BEGIN or ROLLBACK, are tallied as the chaos event "cancel stopped a statement outside pg_warren", not a mismatch. COMMIT is never re-run (a second COMMIT would roll back and report success); a failed one is recorded as the outcome and followed by ROLLBACK. A BEGIN that fails now ends the transaction instead of running its statements outside one.
  • A 57014 on anything else, every pg_warren call included, is judged against ALLOWED as before.

Tests first: test/tests/test_session.py, test/tests/test_pooler_soak_workload.py (299 passed). The soak passed locally on PG 18, also with --chaos-seconds 0.5 (112 cancels). DESIGN.md's M11 pooler-soak note gains a sentence. No CHANGELOG line, as for earlier soak fixes.


Generated by Claude Code

Chaos cancels a pooled backend it saw running a pg_warren call, but
pg_cancel_backend acts on a backend, not a statement: the call can end
before the signal arrives, and the cancel then stops whatever runs next
on that backend. Under transaction pooling that was another client's
session setup (SET statement_timeout), which Session raised as fatal,
failing the soak (CI, "Generators + SQL harness (PG 16)").

No condition in the cancelling statement closes the window between
reading pg_stat_activity and the signal, so the clients tolerate it
where it is harmless: Session runs a setup statement canceled by request
again (counted in canceled_setup), and a workload client does the same
for its BEGIN and ROLLBACK, each tallied as the chaos event "cancel
stopped a statement outside pg_warren". A COMMIT is not run again (once
canceled its transaction is aborted, and a second COMMIT would roll it
back and succeed): it stays the operation's outcome, followed by a
ROLLBACK. A failed BEGIN now ends the transaction rather than letting
its statements run outside one. A cancel of any other statement is still
judged against its operation's allowed failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Rxfe2L3iVjSwSBPdUu1Ke
@wfaithfull
wfaithfull merged commit 28b4341 into main Oct 29, 2026
23 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants