On Wed, Sep 23, 2026 at 2:44 AM Yuhang Qiu <iamqyh@gmail.com> 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-5OU4w@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
