Re: Intermittent buildfarm failures on wrasse
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-15T16:29:20Z
Lists: pgsql-hackers
On Fri, Apr 15, 2022 at 8:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > BTW, before I forget: the wording of this log message is just awful. > On first sight, I thought that it meant that we'd computed OldestXmin > a second time and discovered that it advanced by 26 xids while the VACUUM > was running. > "removable cutoff: %u, which was %d xids old when operation ended\n" How the output appears when placed right before the output describing how VACUUM advanced relfrozenxid is an important consideration. I want the format and wording that we use to imply a relationship between these two things. Right now, that other line looks like this: "new relfrozenxid: %u, which is %d xids ahead of previous value\n" Do you think that this juxtaposition works well? > Also, is it really our practice to spell XID in lower-case in > user-facing messages? There are examples of both. This could easily be changed to "XIDs". -- Peter Geoghegan
Commits
-
Repurpose PROC_COPYABLE_FLAGS as PROC_XMIN_FLAGS
- 8d9d1286acf9 14.4 landed
- 8d061acd12af 15.0 landed
- 5fd0cccc116b 13.8 landed
-
Tighten ComputeXidHorizons' handling of walsenders.
- 6fea65508a1a 15.0 landed
-
Adjust VACUUM's removable cutoff log message.
- 357c8455e649 15.0 landed
-
Temporarily add some probes of tenk1's relallvisible in create_index.sql.
- 5bb2b6abc8d6 15.0 landed
-
Set synchronous_commit=on in test_setup.sql.
- 02fea8fdda65 15.0 cited
-
Rearrange core regression tests to reduce cross-script dependencies.
- cc50080a828d 15.0 cited
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited