Re: Unstable regression test for contrib/pageinspect - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Unstable regression test for contrib/pageinspect
Date
Msg-id CAH2-Wz=3vJhW9CttOREb3ObDq0VdZFUgdgwu1_x=Ra_MFFskDQ@mail.gmail.com
Whole thread Raw
In response to Unstable regression test for contrib/pageinspect  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unstable regression test for contrib/pageinspect
List pgsql-hackers
On Sun, Nov 20, 2022 at 12:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The core reloptions.sql and vacuum.sql tests are two places that are
> also using this option, but they are applying it to temp tables,
> which I think makes it safe (and the lack of failures, seeing that
> they run within parallel test groups, reinforces that).  Can we apply
> that idea in pageinspect?

I believe so. The temp table horizons guarantee isn't all that old, so
the tests may well have been written before it was possible.

> contrib/amcheck and contrib/pg_visibility are also using
> DISABLE_PAGE_SKIPPING, so I wonder if they have similar hazards.
> I haven't seen them fall over, though.

DISABLE_PAGE_SKIPPING forces aggressive mode (which is also possible
with FREEZE), but unlike FREEZE it also forces VACUUM to scan even
all-frozen pages. The other difference is that DISABLE_PAGE_SKIPPING
doesn't affect FreezeLimit/freeze_min_age, whereas FREEZE sets it to
0.

I think that most use of DISABLE_PAGE_SKIPPING by the regression tests
just isn't necessary. Especially where it's combined with FREEZE like
this, as it often seems to be. Why should the behavior around skipping
all-frozen pages (the only thing changed by using
DISABLE_PAGE_SKIPPING on top of FREEZE) actually matter to these
tests?

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: perform_spin_delay() vs wait events
Next
From: Thomas Munro
Date:
Subject: Re: Reducing power consumption on idle servers