Re: Unstable regression test for contrib/pageinspect

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Unstable regression test for contrib/pageinspect
Date: 2022-11-20 21:09:03
Message-ID: CAH2-Wz=3vJhW9CttOREb3ObDq0VdZFUgdgwu1_x=Ra_MFFskDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 20, 2022 at 12:37 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-11-20 21:13:06 Re: Reducing power consumption on idle servers
Previous Message Andres Freund 2022-11-20 20:43:10 perform_spin_delay() vs wait events