On Fri, Sep 30, 2022 at 2:28 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Jaime Casanova <jcasa...@systemguards.com.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
