On Sat, Jun 22, 2024 at 10:53 AM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Sat, Jun 22, 2024 at 10:43 AM Melanie Plageman
> <melanieplageman@gmail.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
