From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: lazy_scan_heap() should release lock on buffer before vacuuming FSM |
Date: | 2023-11-17 21:02:05 |
Message-ID: | 20231117210205.mietw5hyhmlqynb2@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alena Rybakina | 2023-11-17 21:04:12 | Re: [PoC] Reducing planning time when tables have many partitions |
Previous Message | Bruce Momjian | 2023-11-17 21:01:27 | Re: Lifetime of commit timestamps |