Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM - Mailing list pgsql-hackers

From Andres Freund
Subject Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM
Date
Msg-id 20231117210205.mietw5hyhmlqynb2@awork3.anarazel.de
Whole thread Raw
In response to Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM  (Melanie Plageman <melanieplageman@gmail.com>)
List pgsql-hackers
Hi,

On 2023-11-15 16:21:45 -0500, Melanie Plageman wrote:
> On Tue, Nov 14, 2023 at 7:15 PM Andres Freund <andres@anarazel.de> wrote:
> > On 2023-11-14 07:46:10 -0500, Melanie Plageman wrote:
> > > > FreeSpaceMapVacuumRange()'s comment says:
> > > >  * As above, but assume that only heap pages between start and end-1 inclusive
> > > >  * have new free-space information, so update only the upper-level slots
> > > >  * covering that block range.  end == InvalidBlockNumber is equivalent to
> > > >  * "all the rest of the relation".
> > > >
> > > > So FreeSpaceMapVacuumRange(..., blkno) will not actually process the "effects"
> > > > of the RecordPageWithFreeSpace() above it - which seems confusing.
> > >
> > > Ah, so shall I pass blkno + 1 as end?
> >
> > I think there's no actual overflow danger, because MaxBlockNumber + 1 is
> > InvalidBlockNumber, which scans the rest of the relation (i.e. exactly the
> > intended block). Perhaps worth noting?
> 
> Attached

And pushed! Thanks for the report and fix!

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Lifetime of commit timestamps
Next
From: Alena Rybakina
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions