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
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 |