On Wed, Sep 23, 2026 at 2:44 AM Yuhang Qiu <[email protected]> wrote: > The GiST cleanup-lock fix appears to be incomplete on standbys. > gistvacuumpage() already accounts for the root changing from a leaf page > to an internal page while a scan holds a pin, but it only emits VACUUM > WAL when it actually deletes index tuples from a leaf page. > > After a root split, a standby cursor may still hold a batch copied from > the old root leaf, along with a pin on the root buffer. VACUUM acquires > a cleanup lock on the now-internal root on the primary, but there is no > corresponding WAL record to enforce that interlock on the standby. Heap > cleanup and visibility map updates can therefore be replayed while the > cursor still holds the old batch. When the cursor resumes and checks > visibility for the remaining items, it can see the new all-visible bits, > skip the heap checks, and return entries for deleted tuples. The > necessary cleanup-lock barriers need to be WAL-logged even when there > are no tuple deletions.
Essentially the same bug exists in nbtree on master, and on all supported branches, and I don't think it's likely to get fixed anytime soon: https://postgr.es/m/cah2-wzkro678xedorsxrq-ydvp4w7nxybhvjv2mxrztj-5o...@mail.gmail.com Is there any reason to think that the issue is any worse with GiST and SP-GiST using the amgetbatch design, compared to current nbtree? -- Peter Geoghegan
