From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Intermittent buildfarm failures on wrasse
Date: Wed, 13 Apr 2022 21:23:12 -0400
Message-ID: <1401379.1649899392@sss.pgh.pa.us> (raw)
In-Reply-To: <20220414010505.s7z24jxrfsjbzz7l@alap3.anarazel.de>
References: <CAH2-WzkVEJWgJ6FrPd0jNiFo3e4kADNYSDSnQXWQbktqWPZfkA@mail.gmail.com>
<1349964.1649890446@sss.pgh.pa.us>
<CAApHDvrHtXtDCjbdRLJAKOO6warCd4WELxK9tq0mUz3u1OaLOg@mail.gmail.com>
<9F59C4BB-3C82-44B0-9B10-4A2CCC3DE552@anarazel.de>
<CAH2-WzmOJ5YeT1SsBZ7kp2B+EMMVH9RYShornT13oyduEVwKSw@mail.gmail.com>
<1364997.1649893086@sss.pgh.pa.us>
<CAH2-WzkUGqFNXhnFRbVG4xfTo3WpapcdRaH4hQSTrNvDgYvYoQ@mail.gmail.com>
<1365924.1649893883@sss.pgh.pa.us>
<CAH2-Wzn2Obp90oyZa5HN26rzG8ozzHM3dgkpLcsVzxTR+jK5NQ@mail.gmail.com>
<1374062.1649896550@sss.pgh.pa.us>
<20220414010505.s7z24jxrfsjbzz7l@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2022-04-13 20:35:50 -0400, Tom Lane wrote:
>> It seems like a SQL-accessible function could be written
>> and then called before any problematic VACUUM. I like this better
>> for something we're thinking of jamming in post-feature-freeze;
>> we'd not be committing to the feature quite as much as if we
>> added a VACUUM option.
> We could otherwise just disable IOS for that query, for now.
The entire point of that test case is to verify the shape of the
IOS plan, so no that's not an acceptable answer. But if we're
looking for quick hacks, we could do
update pg_class set relallvisible = relpages where relname = 'tenk1';
just before that test.
I'm still suspicious of the pgstat changes, though. I checked into
things here by doing
initdb
edit postgresql.conf to set log_autovacuum_min_duration = 0
pg_ctl start && make installcheck-parallel
and what I see is that the first reported autovacuum activity begins
exactly one minute after the postmaster starts, which is what I'd
expect given the autovacuum naptime rules. On my machine, of course,
the installcheck-parallel run is long gone by then. But even on the
much slower wrasse, we should be well past create_index by the time any
autovac worker launches --- you can see from wrasse's reported test
runtimes that only about 10 seconds have elapsed when it get to the end
of create_index.
This suggests to me that what is holding the (presumed) conflicting
snapshot must be the autovac launcher, because what else could it be?
So I'm suspicious that we broke something in that area, though I am
baffled why only wrasse would be telling us so.
regards, tom lane
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, andres@anarazel.de, pg@bowt.ie, dgrowleyml@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Intermittent buildfarm failures on wrasse
In-Reply-To: <1401379.1649899392@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