Re: The same 2PC data maybe recovered twice
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
Cc: "zhihui.fan1213" <zhihui.fan1213@gmail.com>, pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Date: 2023-07-17T07:59:53Z
Lists: pgsql-bugs, pgsql-hackers
On Mon, Jul 17, 2023 at 02:26:56PM +0800, suyu.cmj wrote:
> Yes, the method you proposed is simpler and more
> efficient. Following your idea, I have modified the corresponding
> patch, hope you can review it when you have time.
I'll double-check that tomorrow, but yes, that's basically what I had
in mind. Thanks for the patch!
+ char path[MAXPGPATH];
+ struct stat stat_buf;
These two variables can be declared in the code block added by the
patch where start_lsn is valid.
+ ereport(FATAL,
+ (errmsg("found unexpected duplicate two-phase
transaction:%u in pg_twophase, check for data correctness.",
+ hdr->xid)));
The last part of this sentence has no need to be IMO, because it is
misleading when building without assertions. How about a single
FATAL/WARNING like that:
- errmsg: "could not recover two-phase state file for transaction %u"
- errdetail: "Two-phase state file has been found in WAL record %X/%X
but this transaction has already been restored from disk."
Then a WARNING simply means that we've skipped the record entirely.
--
Michael
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