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