From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "suyu(dot)cmj" <mengjuan(dot)cmj(at)alibaba-inc(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: The same 2PC data maybe recovered twice |
Date: | 2025-07-09 07:35:23 |
Message-ID: | aG4bu_50RhPGdwSK@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Wed, Jul 09, 2025 at 01:51:03PM +0800, suyu.cmj wrote:
> Currently, since restoreTwoPhaseData() is the only function that
> restores 2PC transactions from disk before the recovery starts,
> after reaching a consistent state, the 2PC transactions are only
> added from the WAL. Under normal circumstances, there should not be
> any corresponding 2PC files on the storage at that point. Therefore,
> I prefer to perform the file access checks only when the server has
> not yet reached a consistent state. Once consistency has been
> reached, if a duplicate 2PC transaction is added, it will directly
> result in an error in the subsequent replay logic.
There is a bit more going on in this code that needs to be fixed.
Please see the following thread, that also relates to the state of the
2PC recovery code when we read them from disk at the beginning of
recovery, with the bottom part being the most relevant:
https://www.postgresql.org/message-id/Z5sd5O9JO7NYNK-C%40paquier.xyz
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2025-07-09 09:21:33 | Re: Unexpected behavior when setting "idle_replication_slot_timeout" |
Previous Message | Hayato Kuroda (Fujitsu) | 2025-07-09 07:24:48 | RE: Unexpected behavior when setting "idle_replication_slot_timeout" |
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-07-09 07:37:11 | Re: Add os_page_num to pg_buffercache |
Previous Message | Bertrand Drouvot | 2025-07-09 07:32:48 | Re: Adding wait events statistics |