Got FATAL in lock_twophase_recover() during recovery

From: "suyu(dot)cmj" <mengjuan(dot)cmj(at)alibaba-inc(dot)com>
To: "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "pgsql-bugs" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Got FATAL in lock_twophase_recover() during recovery
Date: 2023-07-11 02:35:15
Message-ID: 92895db6-5ae2-41f1-8038-302c31712691.mengjuan.cmj@alibaba-inc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi, all.
I want to report a bug about the recovery of two-phase transaction, in current implementation of crash recovery, there are two ways to recover 2pc data:
1、before redo, func restoreTwoPhaseData() will restore 2pc data those xid < ShmemVariableCache->nextXid, which is initialized from checkPoint.nextXid;
2、during redo, func xact_redo() will add 2pc from wal;
The following scenario may cause the same 2pc transaction to be added repeatedly, I have attached a patch for pg11 that reproduces the error:
1、start creating checkpoint_1, checkpoint_1.redo is set as curInsert;
2、before set checkPoint_1.nextXid, a new 2pc is prepared, suppose the xid of this 2pc is 100, and then ShmemVariableCache->nextXid will be advanced as 101;
3、checkPoint_1.nextXid is set as 101;
4、in CheckPointTwoPhase() of checkpoint_1, 2pc_100 won't be copied to disk because its prepare_end_lsn > checkpoint_1.redo;
5、checkPoint_1 is finished, after checkpoint_timeout, start creating checkpoint_2;
6、during checkpoint_2, data of 2pc_100 will be copied to disk;
7、before UpdateControlFile() of checkpoint_2, crash happened;
8、during crash recovery, redo will start from checkpoint_1, and 2pc_100 will be restored first by restoreTwoPhaseData() because xid_100 < checkPoint_1.nextXid, which is 101;
9、because prepare_start_lsn of 2pc_100 > checkpoint_1.redo, 2pc_100 will be added again by xact_redo() during wal replay, resulting in the same 2pc data being added twice;
10、In RecoverPreparedTransactions() -> lock_twophase_recover(), lock the same 2pc will cause FATAL.
After running the patch that reproduced the error, you will get the following error during crash recovery:
2023-07-10 13:04:30.670 UTC [11169] LOG: recovering prepared transaction 569 from shared memory
2023-07-10 13:04:30.670 UTC [11169] LOG: recovering prepared transaction 569 from shared memory
2023-07-10 13:04:30.670 UTC [11169] FATAL: lock ExclusiveLock on object 569/0/0 is already held
2023-07-10 13:04:30.670 UTC [11168] LOG: startup process (PID 11169) exited with exit code 1
2023-07-10 13:04:30.670 UTC [11168] LOG: aborting startup due to startup process failure
I also added a patch for pg11 to fix this problem, hope you can check it when you have time.
Thanks & Best Regard

Attachment Content-Type Size
0001-Reproduce-the-error-in-lock_twophase_recover_11.patch application/octet-stream 6.2 KB
v1-0001-Fix-a-2PC-transaction-maybe-recovered-twice_11.patch application/octet-stream 3.7 KB

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-07-11 06:54:14 Re: BUG #17928: Standby fails to decode WAL on termination of primary
Previous Message Tristan Partin 2023-07-11 00:52:32 Re: BUG #17946: LC_MONETARY & DO LANGUAGE plperl - BUG

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2023-07-11 02:36:09 Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication
Previous Message Amit Kapila 2023-07-11 02:33:14 Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL