Persist coordinator gid in the WAL for crash recovery - #1270
Open
crodas wants to merge 3 commits into
Open
Conversation
Attempt to fix pgdogdev#1175 After a SIGTERM and reboot, prepared 2PC transactions were left orphaned on the shards even with the WAL enabled. Recovery replayed the in-flight transactions but drove COMMIT PREPARED / ROLLBACK PREPARED against a gid that no longer matched what Postgres held, so the statements failed and the monitor retried them forever. The gid a transaction is prepared with embeds a per-process instance_id, which is a fresh random value on every start unless NODE_ID is set. The WAL only persisted the inner transaction id, so a restarted PgDog reconstructed the gid with a different instance_id prefix and missed the orphan. The gid used at recovery must be byte-identical to the gid used at PREPARE, so it has to come from the WAL, not from live process state. Store the full coordinator gid in the Begin and Checkpoint records (serde default keeps old segments readable) and thread it through recovery so cleanup resolves each prepared xact with the exact gid it was created with. Live transactions still render the gid from process state, which is correct in the process that created them. An empty stored gid falls back to the previous behavior. The crash-safety WAL helper now records the full gid too, so the integration spec exercises the real recovery path.
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
levkk
reviewed
Jul 27, 2026
| pub(crate) async fn two_pc_on_guards( | ||
| servers: &mut [Guard], | ||
| transaction: TwoPcTransaction, | ||
| coordinator_gid: &str, |
Collaborator
There was a problem hiding this comment.
I'm not a fan of passing strings around like this (no type safety, easy for a bug to fly through). Could we maybe use the deserialization code in here:
levkk
reviewed
Jul 27, 2026
| /// from re-rendering a [`TwoPcTransaction`] against live process state. | ||
| /// The per-shard participant name is `<coordinator_gid>_<shard>`, matching | ||
| /// [`TwoPcTransactionOnShard`]'s `Display`. | ||
| pub(crate) fn phase_control_gid(coordinator_gid: &str, shard: usize, phase: TwoPcPhase) -> String { |
Collaborator
There was a problem hiding this comment.
Same comment as above. String identifiers generated by calling to_string() or a real Rust type are the root of all evil :)
test_node_id_error asserted node_id() errors when NODE_ID is unset, but node_id() reads the process-global random hex INSTANCE_ID. Roughly 2.3% of the time (all-digit hex) that string parses as a valid u64, so the assertion failed intermittently in CI. Extract the parse into a pure parse_node_id() helper and test it with fixed non-numeric inputs, decoupling the test from the random global. node_id() returns exactly what it did before for every input.
Address review feedback on the WAL gid recovery change: the cleanup path passed the coordinator gid around as a bare string, which is easy to misuse and gives no type safety. Make TwoPcTransaction self-describing instead. It gains an optional gid that Display renders verbatim when set (a transaction rebuilt by WAL recovery, whose gid embeds another process's instance_id that this one cannot reproduce) and renders from live process state when absent. Serialization stays a bare integer via a custom impl, so the on-disk WAL format is unchanged and old segments still decode. The driver functions now take a typed TwoPcTransaction end to end. This removes phase_control_gid, Binding::two_pc_gid, and the separate recovered_gid on TransactionInfo. TwoPcTransaction is no longer Copy because it holds an Arc<str>; call sites clone it explicitly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Attempt to fix #1175
After a SIGTERM and reboot, prepared 2PC transactions were left orphaned on the shards even with the WAL enabled. Recovery replayed the in-flight transactions but drove COMMIT PREPARED / ROLLBACK PREPARED against a gid that no longer matched what Postgres held, so the statements failed and the monitor retried them forever.
The gid a transaction is prepared with embeds a per-process instance_id, which is a fresh random value on every start unless NODE_ID is set. The WAL only persisted the inner transaction id, so a restarted PgDog reconstructed the gid with a different instance_id prefix and missed the orphan. The gid used at recovery must be byte-identical to the gid used at PREPARE, so it has to come from the WAL, not from live process state.
Store the full coordinator gid in the Begin and Checkpoint records (serde default keeps old segments readable) and thread it through recovery so cleanup resolves each prepared xact with the exact gid it was created with. Live transactions still render the gid from process state, which is correct in the process that created them. An empty stored gid falls back to the previous behavior.
The crash-safety WAL helper now records the full gid too, so the integration spec exercises the real recovery path.