renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36022psql -h localhost -U postgresBuilt from patchset v2 (message #2), July 28, 2026 at 08:18 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36022_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36022_2 && git checkout t36022_2Patchset v2 (message #2) is on t36022_2
Upgrading from 9.6 to dev, I now get:
$ rm bisectdata -r ; bisect/bin/pg_ctl initdb -D bisectdata;
bisect/bin/pg_upgrade -b /usr/local/pgsql9_6/bin/ -B bisect/bin/ -d 96 -D
bisectdata/
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?
Culprit is here:
commit 85c11324cabaddcfaf3347df78555b30d27c5b5a
Author: Robert Haas <rhaas@postgresql.org>
Date: Thu Feb 9 16:23:46 2017 -0500
Rename user-facing tools with "xlog" in the name to say "wal".
This means pg_receivexlog because pg_receivewal, pg_resetxlog
becomes pg_resetwal, and pg_xlogdump becomes pg_waldump.
Cheers,
Jeff
On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or
directoryThis 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
On Mon, Feb 13, 2017 at 6:19 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or
directoryThis 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
On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes <jeff.janes@gmail.com> 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.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 14, 2017 at 5:13 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes <jeff.janes@gmail.com> 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