Re: pg_upgrade should truncate/remove its logs before running

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Daniel Gustafsson <daniel@yesql.se>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers@lists.postgresql.org
Date: 2022-01-12T04:08:13Z
Lists: pgsql-hackers
On Wed, Jan 12, 2022 at 12:59:54PM +0900, Michael Paquier wrote:
> On Tue, Jan 11, 2022 at 02:03:07PM -0600, Justin Pryzby wrote:
> > There's no reason not to.  We created the dir, and the user didn't specify to
> > preserve it.  It'd be their fault if they put something valuable there after
> > starting pg_upgrade.
> 
> This is a path for the data internal to pg_upgrade.  My take is that
> the code simplifications the new option brings are more valuable than
> this assumption, which I guess would unlikely happen.  I may be wrong,
> of course.  By the way, while thinking about that, should we worry
> about --logdir="."?

I asked about that before.  Right now, it'll exit(1) when mkdir fails.

I had written a patch to allow "." by skipping mkdir (or allowing it to fail if
errno == EEXIST), but it seems like an awfully bad idea to try to make that
work with rmtree().

-- 
Justin



Commits

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