pg_upgrade should truncate/remove its logs before running
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-12-12T02:50:17Z
Lists: pgsql-hackers
Attachments
- 0001-pg_upgrade-fail-if-logfiles-exist.patch (text/x-diff)
I have seen this numerous times but had not dug into it, until now. 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. I think it should either truncate the logfiles, or error early if any of the files exist. Or it could put all its output files into a newly-created subdirectory. Or this message could be output to the per-db logfiles, and not just the static ones: | "pg_upgrade run on %s". For the per-db logfiels with OIDs in their name, changing open() from "append" mode to truncate mode doesn't work, since they're written to in parallel. They have to be removed/truncated in advance. This is one possible fix. You can test its effect by deliberately breaking one of the calls to exec_progs(), like this. - "\"%s/pg_restore\" %s %s --exit-on-error --verbose " + "\"%s/pg_restore\" %s %s --exit-on-error --verboose "
Commits
-
pg_upgrade: Move all the files generated internally to a subdirectory
- 38bfae365266 15.0 landed