On 1/25/22 04:25, Michael Paquier wrote:
> 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.
I actually tried doing that, but I was not very happy with the result.
The test has to call pg_resetwal, but then it also has to fake pg_xact
data and so on, which seemed a bit ugly so did not include the test in
the patch.
But maybe there's a better way to do this, so here it is. I've kept it
separately, so that it's possible to apply it without the fix, to verify
it actually triggers the issue.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company