Re: pg_upgrade should truncate/remove its logs before running
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@lists.postgresql.org
Date: 2021-12-15T21:17:23Z
Lists: pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes: > On Sat, Dec 11, 2021 at 08:50:17PM -0600, Justin Pryzby wrote: >> If pg_upgrade fails and is re-run, it appends to its logfiles, which is >> confusing since, if it fails again, it then looks like the original error >> recurred and wasn't fixed. The "append" behavior dates back to 717f6d608. > Uh, the database server doesn't erase its logs on crash/failure, so why > should pg_upgrade do that? The server emits enough information so that it's not confusing: there are timestamps, and there's an identifiable startup line. pg_upgrade does neither. If you don't want to truncate as Justin suggests, you should do that instead. Personally I like the idea of making a timestamped subdirectory and dropping all the files in that, because the thing that most annoys *me* about pg_upgrade is the litter it leaves behind in $CWD. A subdirectory would make it far easier to mop up the mess. regards, tom lane
Commits
-
pg_upgrade: Move all the files generated internally to a subdirectory
- 38bfae365266 15.0 landed