Re: The same 2PC data maybe recovered twice

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

In response to

Browse pgsql-bugs by date

  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"

Browse pgsql-hackers by date

  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