From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: New strategies for freezing, advancing relfrozenxid early |
Date: | 2023-01-03 20:30:02 |
Message-ID: | CAH2-Wzk3JpXkEZr8_ZH1jhb2e5Pwqqo_BR6DBWs6swvk0U7yOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 2, 2023 at 6:26 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Mon, 2023-01-02 at 11:45 -0800, Peter Geoghegan wrote:
> > What do you think of the wording adjustments in the attached patch?
> > It's based on your suggested wording.
>
> Great, thank you.
Pushed that today.
Attached is v14.
v14 simplifies the handling of setting the visibility map at the end
of the blkno-wise loop in lazy_scan_heap(). And,
visibilitymap_snap_next() doesn't tell its caller (lazy_scan_heap)
anything about the visibility status of each returned block -- we no
longer need a all_visible_according_to_vm local variable to help with
setting the visibility map.
This new approach to setting the VM is related to hardening that I
plan on adding, which makes the visibility map robust against certain
race conditions that can lead to setting a page all-frozen but not
all-visible. I go into that here:
https://postgr.es/m/CAH2-WznuNGSzF8v6OsgjaC5aYsb3cZ6HW6MLm30X0d65cmSH6A@mail.gmail.com
(It's the second patch -- the first patch already became yesterday's
commit 6daeeb1f.)
In general I don't think that we should be using
all_visible_according_to_vm for anything, especially not anything
critical -- it is just information about how the page used to be in
the past, after all. This will be more of a problem with visibility
map snapshots, since all_visible_according_to_vm could be information
that is hours old by the time it's actually used by lazy_scan_heap().
But it is an existing issue.
BTW, it would be helpful if I could get a +1 to the visibility map
patch posted on that other thread. It's practically a bug fix -- the
VM shouldn't be able to show contradictory information about any given
heap page (i.e. "page is all-frozen but not all-visible"), no matter
what. Just on general principle.
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
v14-0001-Add-eager-and-lazy-freezing-strategies-to-VACUUM.patch | application/x-patch | 19.3 KB |
v14-0003-Finish-removing-aggressive-mode-VACUUM.patch | application/x-patch | 81.4 KB |
v14-0002-Add-eager-and-lazy-VM-strategies-to-VACUUM.patch | application/x-patch | 77.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-01-03 20:30:11 | Why are we using blocking libpq in the backend? |
Previous Message | Robert Haas | 2023-01-03 20:19:43 | Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier |