From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Noah Misch <noah@leadboat.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: David Rowley <dgrowleyml@gmail.com>
Subject: Re: Intermittent buildfarm failures on wrasse
Date: Fri, 15 Apr 2022 12:16:40 -0400
Message-ID: <1648548.1650039400@sss.pgh.pa.us> (raw)
In-Reply-To: <7597CA4E-A58B-4497-A3AE-A24E9BA5294A@anarazel.de>
References: <CAH2-Wz=DHY2LV7=2aVd=qz6AbQhFK7KJRNL5ZwgB7dyno_gzdg@mail.gmail.com>
<1553951.1649975018@sss.pgh.pa.us>
<CAH2-WzngTjUk_65ESmrMf40WTqasrmWG0gpwnvcN+mXsoXT7qQ@mail.gmail.com>
<CAH2-WznXXkkfE_y9ieaHkEQj31HeMAqJBtJPmDY+EpyVg1QywQ@mail.gmail.com>
<1570894.1649986347@sss.pgh.pa.us>
<20220415015249.kfsqxujrf2bn2wz6@alap3.anarazel.de>
<20220415024515.GA862547@rfd.leadboat.com>
<20220415051205.6abhlilh6fnjgohr@alap3.anarazel.de>
<20220415052125.GD862547@rfd.leadboat.com>
<1637671.1650032132@sss.pgh.pa.us>
<20220415151210.itzv6fh4ez6yo2np@alap3.anarazel.de>
<7597CA4E-A58B-4497-A3AE-A24E9BA5294A@anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> Off for a bit, but I realized that we likely don't exclude the launcher because it's not database associated...
Yeah. I think this bit in ComputeXidHorizons needs rethinking:
/*
* Normally queries in other databases are ignored for anything but
* the shared horizon. ...
*/
if (in_recovery ||
MyDatabaseId == InvalidOid || proc->databaseId == MyDatabaseId ||
proc->databaseId == 0) /* always include WalSender */
{
The "proc->databaseId == 0" business apparently means to include only
walsender processes, and it's broken because that condition doesn't
include only walsender processes.
At this point we have the following conclusions:
1. A slow transaction in the launcher's initial get_database_list()
call fully explains these failures. (I had been thinking that the
launcher's xact would have to persist as far as the create_index
script, but that's not so: it only has to last until test_setup
begins vacuuming tenk1. The CREATE INDEX steps are not doing any
visibility map changes of their own, but what they are doing is
updating relallvisible from the results of visibilitymap_count().
That's why they undid the effects of manually poking relallvisible,
without actually inserting any data better than what the initial
VACUUM computed.)
2. We can probably explain why only wrasse sees this as some quirk
of the Solaris scheduler. I'm satisfied to blame it-happens-in-
installcheck-but-not-check on that too.
3. It remains unclear why we suddenly started seeing this last week.
I suppose it has to be a side-effect of the pgstats changes, but
the mechanism is obscure. Probably not worth the effort to pin
down exactly why.
As for fixing it, what I think would be the preferable answer is to
fix the above-quoted logic so that it indeed includes only walsenders
and not random other background workers. (Why does it need to include
walsenders, anyway? The commentary sucks.) Alternatively, or perhaps
also, we could do what was discussed previously and make a hack to
allow delaying vacuum until the system is quiescent.
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, noah@leadboat.com, pg@bowt.ie, dgrowleyml@gmail.com
Subject: Re: Intermittent buildfarm failures on wrasse
In-Reply-To: <1648548.1650039400@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