| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
| Date: | 2026-09-18 21:39:36 |
| Message-ID: | CAAKRu_amj7qLF4c=9ijd=708Fu2G8gg-2EqwBu=aCdAHU2sPHg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 14, 2026 at 12:02 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
>
> I've also pushed a fix for this.
Continuing to probe these patches with an LLM found a few more minor oversights.
0001 adds an assert to protect against silently leaking a VM pin when
the wrong VM page is passed to heap_page_prune_and_freeze(). This
should be caught in development, so I think an assert is sufficient.
0002 downgrades the lock required in recovery to replay a
VM-update-only record from cleanup to exclusive. Pruning and freezing
always required a cleanup lock in recovery but now that you can end up
just setting the VM with the same record type, you should still be
able to do that with only an exclusive lock to avoid canceled queries
on a standby.
0003 allows a few more cases to set the VM on-access than before.
Usually this would be an enhancement. But, I argue it is backpatchable
because in 19 we started setting pd_prune_xid on insert so that we
could set the page all-visible in the VM during read-only queries, and
there are a few cases where we will do all the work to do that and
then not set it in the VM because we thought it would require an extra
FPI but it turns out it actually will not. So we added a cycle of work
for no gain without the patch. The details are described in the patch
comment and commit message.
0004 I'm not really considering backpatching but it does seem like
strictly an improvement. Without it, if a page has only live tuples
but any of them are too new to be all-visible, we'll clear
pd_prune_xid which means we won't revisit the page to try to set it
all-visible in future queries. This patch instead updates pd_prune_xid
with the newest live xid, so that on-access pruning will set it
all-visible in the future once the visibility horizon is past that
xid.
I'll want review on 0002 and 0003 before pushing (and 0001 is assert
only), so I'll probably let these slide until after beta 4 code
freeze.
- Melanie
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Assert-correct-VM-page-passed-to-pruning.patch | text/x-patch | 1.6 KB |
| 0002-Avoid-cleanup-lock-in-recovery-if-only-setting-VM.patch | text/x-patch | 1.6 KB |
| 0003-Correct-on-access-VM-setting-heuristic.patch | text/x-patch | 11.1 KB |
| 0004-Retain-newest-live-xid-as-prune-hint-after-visibilit.patch | text/x-patch | 2.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Sami Imseih | 2026-09-18 21:19:20 | Add REPACK progress phases for logical decoding setup |