From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(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-24 21:28:43 |
Message-ID: | A890C641-2858-40EA-8B9A-D50EAA2EBD44@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/22/22, 4:43 PM, "Tomas Vondra" <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> There's a bug in ProcArrayApplyRecoveryInfo, introduced by 8431e296ea,
> which may cause failures when starting a replica, making it unusable.
> The commit message for 8431e296ea is not very clear about what exactly
> is being done and why, but the root cause is that at while processing
> RUNNING_XACTS, the XIDs are sorted like this:
>
> /*
> * Sort the array so that we can add them safely into
> * KnownAssignedXids.
> */
> qsort(xids, nxids, sizeof(TransactionId), xidComparator);
>
> where "safely" likely means "not violating the ordering expected by
> KnownAssignedXidsAdd". Unfortunately, xidComparator compares the values
> as plain uint32 values, while KnownAssignedXidsAdd actually calls
> TransactionIdFollowsOrEquals() and compares the logical XIDs :-(
Wow, nice find.
> This likely explains why we never got any reports about this - most
> systems probably don't leave transactions running for this long, so the
> probability is much lower. And replica restarts are generally not that
> common events either.
I'm aware of one report with the same message [0], but I haven't read
closely enough to determine whether it is the same issue. It looks
like that particular report was attributed to backup_label being
removed.
> 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.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-24 21:31:08 | Re: [BUG]Update Toast data failure in logical replication |
Previous Message | Andres Freund | 2022-01-24 21:28:13 | Re: Why is src/test/modules/committs/t/002_standby.pl flaky? |