From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Unstable regression test for contrib/pageinspect
Date: Sun, 20 Nov 2022 15:37:26 -0500
Message-ID: <2892135.1668976646@sss.pgh.pa.us> (raw)
My very slow buildfarm animal mamba has failed pageinspect
several times [1][2][3][4] with this symptom:
diff -U3 /home/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/expected/page.out /home/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/results/page.out
--- /home/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/expected/page.out 2022-11-20 10:12:51.780935488 -0500
+++ /home/buildfarm/bf-data/HEAD/pgsql.build/contrib/pageinspect/results/page.out 2022-11-20 14:00:25.818743985 -0500
@@ -92,9 +92,9 @@
SELECT t_infomask, t_infomask2, raw_flags, combined_flags
FROM heap_page_items(get_raw_page('test1', 0)),
LATERAL heap_tuple_infomask_flags(t_infomask, t_infomask2);
- t_infomask | t_infomask2 | raw_flags | combined_flags
-------------+-------------+-----------------------------------------------------------+--------------------
- 2816 | 2 | {HEAP_XMIN_COMMITTED,HEAP_XMIN_INVALID,HEAP_XMAX_INVALID} | {HEAP_XMIN_FROZEN}
+ t_infomask | t_infomask2 | raw_flags | combined_flags
+------------+-------------+-----------------------------------------+----------------
+ 2304 | 2 | {HEAP_XMIN_COMMITTED,HEAP_XMAX_INVALID} | {}
(1 row)
-- tests for decoding of combined flags
It's not hard to guess what the problem is here: the immediately preceding
bit is hopelessly optimistic.
-- If we freeze the only tuple on test1, the infomask should
-- always be the same in all test runs.
VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) test1;
The fact that you asked for a freeze doesn't mean you'll get a freeze.
I suppose that a background auto-analyze is holding back global xmin
so that the tuple doesn't actually get frozen.
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?
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.
regards, tom lane
[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2022-11-20%2015%3A13%3A19
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2022-10-31%2013%3A33%3A35
[3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2022-10-19%2016%3A34%3A07
[4] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mamba&dt=2022-08-29%2017%3A49%3A02
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org
Subject: Re: Unstable regression test for contrib/pageinspect
In-Reply-To: <2892135.1668976646@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox