Re: Intermittent buildfarm failures on wrasse
От | Tom Lane |
---|---|
Тема | Re: Intermittent buildfarm failures on wrasse |
Дата | |
Msg-id | 1349964.1649890446@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Intermittent buildfarm failures on wrasse (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Intermittent buildfarm failures on wrasse
Re: Intermittent buildfarm failures on wrasse Re: Intermittent buildfarm failures on wrasse |
Список | pgsql-hackers |
Peter Geoghegan <pg@bowt.ie> writes: > On Wed, Apr 13, 2022 at 3:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm tempted to add something like >> SELECT relallvisible = relpages FROM pg_class WHERE relname = 'tenk1'; >> so that we can confirm or refute the theory that relallvisible is >> the driving factor. > It would be fairly straightforward to commit a temporary debugging > patch that has the autovacuum logging stuff report directly on how > VACUUM set new_rel_allvisible in pg_class. We should probably be doing > that already, just because it's useful information that is already > close at hand. Doesn't look like wrasse has autovacuum logging enabled, though. After a bit more navel-contemplation I see a way that the pgstats work could have changed timing in this area. We used to have a rate limit on how often stats reports would be sent to the collector, which'd ensure half a second or so delay before a transaction's change counts became visible to the autovac daemon. I've not looked at the new code, but I'm betting that that's gone and the autovac launcher might start a worker nearly immediately after some foreground process finishes inserting some rows. So that could result in autovac activity occurring concurrently with test_setup where it didn't before. As to what to do about it ... maybe apply the FREEZE and DISABLE_PAGE_SKIPPING options in test_setup's vacuums? It seems like DISABLE_PAGE_SKIPPING is necessary but perhaps not sufficient. regards, tom lane
В списке pgsql-hackers по дате отправления: