8000 Fix recovery of 2PC transaction during crash recovery · postgres/postgres@bc0581f · GitHub
[go: up one dir, main page]

Skip to content

Commit bc0581f

Browse files
committed
Fix recovery of 2PC transaction during crash recovery
A crash in the middle of a checkpoint with some two-phase state data already flushed to disk by this checkpoint could cause a follow-up crash recovery to recover twice the same transaction, once from what has been found in pg_twophase/ at the beginning of recovery and a second time when replaying its corresponding record. This would lead to FATAL failures in the startup process during recovery, where the same transaction would have a state recovered twice instead of once: LOG: recovering prepared transaction 731 from shared memory LOG: recovering prepared transaction 731 from shared memory FATAL: lock ExclusiveLock on object 731/0/0 is already h 8000 eld This issue is fixed by skipping the addition of any 2PC state coming from a record whose equivalent 2PC state file has already been loaded in TwoPhaseState at the beginning of recovery by restoreTwoPhaseData(), which is OK as long as the system has not reached a consistent state. The timing to get a messed up recovery processing is very racy, and would very unlikely happen. The thread that has reported the issue has demonstrated the bug using injection points to force a PANIC in the middle of a checkpoint. Issue introduced in 728bd99, so backpatch all the way down. Reported-by: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com> Author: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com> Author: Michael Paquier Discussion: https://postgr.es/m/109e6994-b971-48cb-84f6-829646f18b4c.mengjuan.cmj@alibaba-inc.com Backpatch-through: 11
1 parent db98138 commit bc0581f

File tree

1 file changed

+33
-0
lines changed

1 file changed

+33
-0
lines changed

src/backend/access/transam/twophase.c

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2509,6 +2509,39 @@ PrepareRedoAdd(char *buf, XLogRecPtr start_lsn,
25092509
* that it got added in the redo phase
25102510
*/
25112511

2512+
/*
2513+
* In the event of a crash while a checkpoint was running, it may be
2514+
* possible that some two-phase data found its way to disk while its
2515+
* corresponding record needs to be replayed in the follow-up recovery.
2516+
* As the 2PC data was on disk, it has already been restored at the
2517+
* beginning of recovery with restoreTwoPhaseData(), so skip this record
2518+
* to avoid duplicates in TwoPhaseState. If a consistent state has been
2519+
* reached, the record is added to TwoPhaseState and it should have no
2520+
* corresponding file in pg_twophase.
2521+
*/
2522+
if (!XLogRecPtrIsInvalid(start_lsn))
2523+
{
2524+
char path[MAXPGPATH];
2525+
2526+
TwoPhaseFilePath(path, hdr->xid);
2527+
2528+
if (access(path, F_OK) == 0)
2529+
{
2530+
ereport(reachedConsistency ? ERROR : WARNING,
2531+
(errmsg("could not recover two-phase state file for transaction %u",
2532+
hdr->xid),
2533+
errdetail("Two-phase state file has been found in WAL record %X/%X, but this transaction has already been restored from disk.",
2534+
(uint32) (start_lsn >> 32),
2535+
(uint32) start_lsn)));
2536+
return;
2537+
}
2538+
2539+
if (errno != ENOENT)
2540+
ereport(ERROR,
2541+
(errcode_for_file_access(),
2542+
errmsg("could not access file \"%s\": %m", path)));
2543+
}
2544+
25122545
/* Get a free gxact from the freelist */
25132546
if (TwoPhaseState->freeGXacts == NULL)
25142547
ereport(ERROR,

0 commit comments

Comments
 (0)
0