Re: The same 2PC data maybe recovered twice
suyu.cmj <mengjuan.cmj@alibaba-inc.com>
From: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
To: "Andy Fan" <zhihui.fan1213@gmail.com>
Cc: "pgsql-bugs" <pgsql-bugs@lists.postgresql.org>
Date: 2023-07-12T07:20:57Z
Lists: pgsql-bugs, pgsql-hackers
Attachments
- 0001-Reproduce-the-error_master.patch (application/octet-stream) patch 0001
Yes, this bug can also be reproduced on the master branch, and the corresponding reproduction patch is attached. I also considered comparing the 2pc.prepare_start_lsn and checkpoint.redo in ProcessTwoPhaseBuffer before, but this method requires modifying the format of the 2pc checkpoint file, which will bring compatibility issues. Especially for released branches, assuming that a node has encountered this bug, it will not be able to start successfully due to FATAL during crash recovery, and therefore cannot manually commit previous two-phase transactions. Using magic number to distinguish 2pc checkpoint file versions can't solve the problem in the above scenario either. For unreleased branches, writing 2pc.prepare_start_lsn into the checkpoint file will be a good solution, but for released branches, I personally think using WAL record to overwrite checkpoint data would be a more reasonable approach, What do you think? Best Regards suyu.cmj
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix recovery of 2PC transaction during crash recovery
- bc0581f8fb8b 11.21 landed
- d2ee542a2bbe 12.16 landed
- db59108a2b67 13.12 landed
- 442749100d34 14.9 landed
- a878eff6b4b9 15.4 landed
- f88bc9f38839 16.0 landed
- cb0cca188072 17.0 landed