Re: Intermittent buildfarm failures on wrasse

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-15T17:43:22Z
Lists: pgsql-hackers
Hi,

On 2022-04-15 10:23:56 -0700, Peter Geoghegan wrote:
> On Fri, Apr 15, 2022 at 10:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > As well as the age of OldestXmin at the start of VACUUM.
> >
> > Is it worth capturing and logging both of those numbers?  Why is
> > the age at the end more interesting than the age at the start?
> 
> As Andres said, that's often more interesting because most of the time
> OldestXmin is not held back by much (not enough to matter).

I think it'd be interesting - particularly for large relations or when
looking to adjust autovac cost limits. It's not rare for autovac to take
long enough that another autovac is necessary immediately again. Also
helps to interpret the "dead but not yet removable" counts.

Something like:
removable cutoff: %u, age at start: %u, age at end: %u...

Greetings,

Andres Freund



Commits

  1. Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGS

  2. Tighten ComputeXidHorizons' handling of walsenders.

  3. Adjust VACUUM's removable cutoff log message.

  4. Temporarily add some probes of tenk1's relallvisible in create_index.sql.

  5. Set synchronous_commit=on in test_setup.sql.

  6. Rearrange core regression tests to reduce cross-script dependencies.

  7. snapshot scalability: Don't compute global horizons while building snapshots.