Re: pgsql: Avoid improbable PANIC during heap_update.

On Fri, Sep 30, 2022 at 2:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> > Just to confirm I saw this on RC1
>
> Ugh ... I think I see the problem. There's still one path through
> RelationGetBufferForTuple that fails to guarantee that it's acquired
> a vmbuffer pin if the all-visible flag becomes set in the otherBuffer.

> It'd still be good to have a test case for this ...

FWIW it seems possible that the Postgres 15 vacuumlazy.c work that
added lazy_scan_noprune() made this scenario more likely in practice
-- even compared to Postgres 14.

Note that VACUUM will collect preexisting LP_DEAD items in heap pages
that cannot be cleanup locked during VACUUM's first heap pass in
Postgres 15 (in lazy_scan_noprune). There is no need for a cleanup
lock in the second heap pass, either (that details is the same as 14,
but not earlier versions). So 15 is the first version that doesn't
need a cleanup lock in either the first heap pass or the second heap
pass to be able to set the heap page all-visible. That difference
seems like it could be "protective" on 14, especially when vacuuming
smaller tables.

--
Peter Geoghegan