Re: Bug in ProcArrayApplyRecoveryInfo for snapshots crossing 4B, breaking replicas

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bug in ProcArrayApplyRecoveryInfo for snapshots crossing 4B, breaking replicas
Date: 2022-01-25 03:25:19
Message-ID: Ye9tn5imsHLLuLmK@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 24, 2022 at 10:45:48PM +0100, Tomas Vondra wrote:
> On 1/24/22 22:28, Bossart, Nathan wrote:
>>> Attached patch is fixing this by just sorting the XIDs logically. The
>>> xidComparator is meant for places that can't do logical ordering. But
>>> these XIDs come from RUNNING_XACTS, so they actually come from the same
>>> wraparound epoch (so sorting logically seems perfectly fine).
>>
>> The patch looks reasonable to me.
>
> Thanks!

Could it be possible to add a TAP test? One idea would be to rely on
pg_resetwal -x and -e close to the 4B limit to set up a node before
stressing the scenario of this bug, so that would be rather cheap.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinoda, Noriyoshi (PN Japan FSIP) 2022-01-25 03:54:52 RE: refactoring basebackup.c
Previous Message houzj.fnst@fujitsu.com 2022-01-25 03:18:17 RE: row filtering for logical replication