Re: Unstable regression test for contrib/pageinspect
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-11-20T21:09:03Z
Lists: 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
Commits
-
Stabilize test of BRIN parallel create
- 4d916dd876c3 17.0 landed
-
Prevent instability in contrib/pageinspect's regression test.
- ff9d27ee2b8b 15.2 landed
- e2933a6e1179 16.0 landed
- 5cda142bb9d2 14.7 landed