Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
On Tue, Feb 14, 2017 at 5:13 PM, Michael Paquierwrote: > On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes wrote: >> I thought people would object to checking the version number in two >> different places to make the same fundamental decision, and would want that >> refactored somehow. But if you are OK with it, then I am. > > The binary versions are checked only once, which does not with change > HEAD. With this patch it happens just earlier, which makes the most > sense now that we have a condition depending on the version of what is > installed. Thanks, Michael! Committed. I actually thought about this problem when I committed the original patch but decided it ought to be OK because I didn't see why we'd be running pg_resetxlog on the old cluster. I didn't think about the fact that we might be running it with the -n option. Oops. Thanks Jeff for the report. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janeswrote: > I thought people would object to checking the version number in two > different places to make the same fundamental decision, and would want that > refactored somehow. But if you are OK with it, then I am. The binary versions are checked only once, which does not with change HEAD. With this patch it happens just earlier, which makes the most sense now that we have a condition depending on the version of what is installed. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
On Mon, Feb 13, 2017 at 6:19 PM, Michael Paquierwrote: > On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes wrote: > > check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or > > directory > > > > This looks somewhat complicated to fix. Should check_bin_dir test the > old > > cluster version, and make a deterministic check based on that? Or just > > check for either spelling, and stash the successful result somewhere? > > The fix does not seem that complicated to me. get_bin_version() just > needs pg_ctl to be present, so we could move that in check_bin_dir() > after looking if pg_ctl is in a valid state, and reuse the version of > bin_version to see if the binary version is post-10 or not. Then the > decision making just depends on this value. Please see the patch > attached, this is passing 9.6->10 and check-world. > That fixes it for me. I thought people would object to checking the version number in two different places to make the same fundamental decision, and would want that refactored somehow. But if you are OK with it, then I am. Cheers, Jeff
Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janeswrote: > check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or > directory > > This looks somewhat complicated to fix. Should check_bin_dir test the old > cluster version, and make a deterministic check based on that? Or just > check for either spelling, and stash the successful result somewhere? The fix does not seem that complicated to me. get_bin_version() just needs pg_ctl to be present, so we could move that in check_bin_dir() after looking if pg_ctl is in a valid state, and reuse the version of bin_version to see if the binary version is post-10 or not. Then the decision making just depends on this value. Please see the patch attached, this is passing 9.6->10 and check-world. I have added as well an open item on the wiki. -- Michael pgupgrade-rename-fix.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers