Re: A test for replay of regression tests - Mailing list pgsql-hackers

From Andres Freund
Subject Re: A test for replay of regression tests
Date
Msg-id 20220325041607.3vcnw34wxoucb5zy@alap3.anarazel.de
Whole thread Raw
In response to Re: A test for replay of regression tests  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: A test for replay of regression tests  (Thomas Munro <thomas.munro@gmail.com>)
Re: A test for replay of regression tests  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2022-03-24 21:06:21 -0700, Peter Geoghegan wrote:
> On Thu, Mar 24, 2022 at 8:56 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Interesting.  IIUC your chaos gizmo shows that particular vacuum test
> > still failing on master, but that wouldn't happen in real life because
> > since 383f2221 it's a temp table.  Your gizmo should probably detect
> > temp rels, as your comment says.  I was sort of thinking that perhaps
> > if DISABLE_PAGE_SKIPPING is eventually made to do what its name sounds
> > like it does, we could remove TEMP from that test and it'd still pass
> > with the gizmo...
> 
> Why not just use VACUUM FREEZE? That should work, because it won't
> settle for a cleanup lock on any page with an XID < OldestXmin. And
> even if there were only LP_DEAD items on a page, that wouldn't matter
> either, because we don't need a cleanup lock to get rid of those
> anymore. And we consistently do all the same steps for rel truncation
> in the no-cleanup-lock path (lazy_scan_noprune) now.
> 
> I think that DISABLE_PAGE_SKIPPING isn't appropriate for this kind of
> thing. It mostly just makes VACUUM not trust the visibility map, which
> isn't going to help. While DISABLE_PAGE_SKIPPING also forces
> aggressive mode, that isn't going to help either, unless you somehow
> also make sure that FreezeLimit is OldestXmin (e.g. by setting
> vacuum_freeze_min_age to 0).
> 
> VACUUM FREEZE (without DISABLE_PAGE_SKIPPING) seems like it would do
> everything you want, without using a temp table. At least on the
> master branch.

We tried that in a prior case:
https://postgr.es/m/20220120052404.sonrhq3f3qgplpzj%40alap3.anarazel.de

I don't know if the same danger applies here though.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Corruption during WAL replay
Next
From: Julien Rouhaud
Date:
Subject: Re: Schema variables - new implementation for Postgres 15