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
-
pg_upgrade: Move all the files generated internally to a subdirectory
- 38bfae365266 15.0 landed