Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date
Msg-id CAAKRu_aR6e2mNVo-DNHDUfBE5i0cbE4=u=_Qi9+v573qiGtBig@mail.gmail.com
Whole thread
In response to Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
List pgsql-hackers
On Tue, Apr 21, 2026 at 5:37 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Mon, Apr 20, 2026 at 12:18 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
> >
> >
> > Yes, I think changing it to a temp table is the easiest fix. We could
> > also do autovacuum_enabled=false, I think, but making it a temp table
> > seems cleanest.
> >
> > I wonder if we should move the EXPLAIN test above the results queries,
> > then throw in a vacuum in between some of them so we exercise btree
> > gist as a bitmap heap scan and as an index only scan. It could provide
> > a little bit more coverage? Or maybe that isn't actually extra
> > coverage. I'm not sure.
>
> I kept it simple and just committed making it a temp table in 62407d26b7c

An adversarial LLM review of this patch series found that I call
visibilitymap_pin() after taking a cleanup lock on the heap page in
the on-access pruning path -- which is not good. Here is a small patch
to fix that. Doing it before we're sure we can get the cleanup lock
could occasionally lead to an unneeded pin, but such situations should
be uncommon.

 - Melanie

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Rename PqMsg_Progress to PqMsg_ParallelWorkerProgress
Next
From: Tom Lane
Date:
Subject: Re: Add PRODUCT() aggregate function