Re: Berserk Autovacuum (let's save next Mandrill) - Mailing list pgsql-hackers

From David Rowley
Subject Re: Berserk Autovacuum (let's save next Mandrill)
Date
Msg-id CAApHDvrx1KGMdgn7q0JdqX8W3MgyEsF2F4O07WC0muscmScuTg@mail.gmail.com
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)
List pgsql-hackers
On Thu, 2 Apr 2020 at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> > Yeah, that makes sense. I still can't see what might be causing those
> > failures. The tests that were doing an ALTER COLUMN and then expecting
> > to see the results of a non-analysed table ought to be fixed by
> > 0936d1b6f, but that doesn't match the buildfarm failures. Possibly
> > 0936d1b6f will help with those anyway, but if so, it'll be annoying
> > not understanding why.
>
> Quite :-(.  While it's too early to declare victory, we've seen no
> more failures of this ilk since 0936d1b6f, so it's sure looking like
> autovacuum did have something to do with it.

How about [1]? It seems related to me and also post 0936d1b6f.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lousyjack&dt=2020-04-01%2017%3A03%3A05



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench - add \aset to store results of a combined query
Next
From: Michael Paquier
Date:
Subject: Re: ALTER tbl rewrite loses CLUSTER ON index