Re: pg_upgrade should truncate/remove its logs before running

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Justin Pryzby <pryzby@telsasoft.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Daniel Gustafsson <daniel@yesql.se>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers@lists.postgresql.org
Date: 2022-02-07T00:33:13Z
Lists: pgsql-hackers
On Sun, Feb 06, 2022 at 08:32:59AM -0500, Andrew Dunstan wrote:
> *sigh* Sometimes I have a mind like a sieve. I prepped the release a few
> days ago and meant to come back the next morning and send out emails
> announcing it, as well as rolling it out to my animals, and got diverted
> so that didn't happen and it slipped my mind. I'll go and do those
> things now.

Thanks.  I saw the release listed after a couple of days of
hibernation, and that one week went by since, so I thought that the
timing was pretty good.  I did not check the buildfarm members though,
sorry about that.

> But the commit really shouldn't have happened until we know that most
> buildfarm owners have installed it. It should have waited wait not just
> for the release but for widespread deployment. Otherwise we will just
> lose any logging for an error that might appear.

Would it be better if I just revert the change for now then and do it
again in one/two weeks?  The buildfarm is green, so keeping things as 
they are does not sound like a huge deal to me, either, for this
case.

FWIW, I have already switched my own animal to use the newest
buildfarm client.
--
Michael

Commits

  1. pg_upgrade: Move all the files generated internally to a subdirectory