Re: FreezeLimit underflows in pg14 and 15 causing incorrect behavior in heap_prepare_freeze_tuple

On Sat, Jun 22, 2024 at 10:53 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Sat, Jun 22, 2024 at 10:43 AM Melanie Plageman
> <melanieplageman(at)gmail(dot)com> wrote:
> > Hmm. So perhaps this subtraction results in the desired behavior for
> > freeze limit -- but by using FreezeLimit as the cutoff_xid for
> > heap_prepare_freeze_tuple(), you can still end up considering freezing
> > tuples with xmax older than OldestXmin.
>
> Using a FreezeLimit > OldestXmin is just wrong. I don't think that
> that even needs to be discussed.

Because it is an unsigned int that wraps around, FreezeLimit can
precede OldestXmin, but we can have a tuple whose xmax precedes
OldestXmin but does not precede FreezeLimit. So, the question is if it
is okay to freeze tuples whose xmax precedes OldestXmin but follows
FreezeLimit.

> > This results in erroring out with "cannot freeze committed xmax" on 16
> > and master but not erroring out like this in 14 and 15 for the same
> > tuple and cutoff values.
>
> I don't follow. I thought that 16 and master don't have this
> particular problem? Later versions don't use safeLimit as FreezeLimit
> like this.

Yes, 16 and master don't consider freezing a tuple with an xmax older
than OldestXmin because they use OldestXmin for cutoff_xid and that
errors out in heap_prepare_freeze_tuple(). 14 and 15 (and maybe
earlier, but I didn't check) use FreezeLimit so they do consider
freezing tuple with xmax older than OldestXmin.

- Melanie