Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae - Mailing list pgsql-bugs

From Melanie Plageman
Subject Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
Date
Msg-id CAAKRu_bzcKmb1G4wY2AezsDbZ5QZubmrjrKgkPdbu_L6k6uUdQ@mail.gmail.com
Whole thread Raw
In response to Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae  (Bowen Shi <zxwsbg12138@gmail.com>)
Responses Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae
List pgsql-bugs
On Sun, May 12, 2024 at 11:19 PM Bowen Shi <zxwsbg12138@gmail.com> wrote:
>
> Hi,
>>
>> Obviously we should actually fix this on back branches, but could we
>> at least make the retry loop interruptible in some way so people could
>> use pg_cancel/terminate_backend() on a stuck autovacuum worker or
>> vacuum process?
>
>
> If the problem happens in versions <= PG 16, we don't have a good solution (vacuum process holds the exclusive lock
causecheckpoint hangs). 
>
> Maybe we can make the retry loop interruptible first. However, since we are using START_CRIT_SECTION, we cannot
simplyuse CHECK_FOR_INTERRUPTS to handle it. 

As far as I can tell, in 14 and 15, the versions where the issue
reported here is present, there is not a critical section in the
section of code looped through in the retry loop in lazy_scan_prune().
We can actually fix the particular issue I reproduced with the
attached patch. However, I think it is still worth making the retry
loop interruptible in case there are other ways to end up infinitely
looping in the retry loop in lazy_scan_prune().

- Melanie

Attachment

pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: ORDER BY two columns gives incorrect result on second column
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #18377: Assert false in "partdesc->nparts >= pinfo->nparts", fileName="execPartition.c", lineNumber=1943