From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Noah Misch <noah(at)leadboat(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Intermittent buildfarm failures on wrasse |
Date: | 2022-04-15 01:52:49 |
Message-ID: | 20220415015249.kfsqxujrf2bn2wz6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-04-14 21:32:27 -0400, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > Are you aware of Andres' commit 02fea8fd? That work prevented exactly
> > the same set of symptoms (the same index-only scan create_index
> > regressions),
>
> Hm. I'm starting to get the feeling that the real problem here is
> we've "optimized" the system to the point where repeatable results
> from VACUUM are impossible :-(
The synchronous_commit issue is an old one. It might actually be worth
addressing it by flushing out pending async commits out instead. It just
started to be noticeable when tenk1 load and vacuum were moved closer.
What do you think about applying a polished version of what I posted in
https://postgr.es/m/20220414164830.63rk5zqsvtqqk7qz%40alap3.anarazel.de
? That'd tell us a bit more about the horizon etc.
It doesn't have to be the autovacuum launcher. I think it shouldn't even
be taken into account - it's not database connected, and tenk1 isn't a
shared relation. All very odd.
It's also interesting that it only happens in the installcheck cases,
afaics, not the check ones. Although that might just be because there's
more of them...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-04-15 01:53:34 | Re: Intermittent buildfarm failures on wrasse |
Previous Message | Peter Geoghegan | 2022-04-15 01:49:48 | Re: Intermittent buildfarm failures on wrasse |