Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: "Bossart, Nathan" <bossartn@amazon.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-25T03:25:19Z
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

Commits

  1. Fix ordering of XIDs in ProcArrayApplyRecoveryInfo