Обсуждение: Problem with pg_upgrade 9.2 on Windows
Hello all, I get the following output from pg_upgrade when trying to upgrade a test cluster on Windows 7 x64: c:\Daten>path PATH=c:\windows;c:\windows\system32;c:\Program Files\PostgreSQL\9.2\bin c:\Daten>pg_upgrade --old-bindir="c:\Program Files\PostgreSQL\9.1\bin" --new-bindir="c:\Program Files\PostgreSQL\9.2\bin" --old-datadir="c:\Daten\db\pgsql" --new-datadir=c:\Daten\db\pgsql-9.2\data --old-port=5432 --new-port=5433 --user=postgres --verbose --check [...] Checking for contrib/isn with bigint-passing mismatch ok ""c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" stop >> "pg_upgrade_utility.log" 2>&1" pg_ctl: no operation specified Try "pg_ctl --help" for more information. *failure* There were problems executing """c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" stop >> "pg_upgrade_utility.log" 2>&1"" Consult the last few lines of "pg_upgrade_utility.log" for the probable cause of the failure. Failure, exiting ""c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" -m fast stop >> "pg_upgrade_utility.log" 2>&1" pg_ctl: no operation specified Try "pg_ctl --help" for more information. *failure* There were problems executing """c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" -m fast stop >> "pg_upgrade_utility.log" 2>&1"" Consult the last few lines of "pg_upgrade_utility.log" for the probable cause of the failure. If needed, I can provide the full output of pg_upgrade, but it does not indicate any other problems. Man's best friend, procmon, shows the following command lines for the last three invocations of pg_ctl: "c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "c:\Daten\db\pgsql" -o "-p 5432 -b " start "c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o " stop >> "pg_upgrade_utility.log" 2>&1" "c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o " -m fast stop >> "pg_upgrade_utility.log" 2>&1" As you can see, the two failing commands (the last two) are missing the second quote for the empty -o option. This pulled the remainder of the command line, including the operation and the output redirection, into the -o option's value. The output from pg_upgrade itself, as well as the referenced log file (see below) have such an unintelligible mess of quotation marks that I cannot tell whether it's correct there. pg_upgrade_utility.log: command: ""c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" stop >> "pg_upgrade_utility.log" 2>&1" command: ""c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D "c:\Daten\db\pgsql" -o "" -m fast stop >> "pg_upgrade_utility.log" 2>&1" Is there anything I can do to avoid this? Should I report it as a bug? -- Christian
On Thu, Sep 13, 2012 at 02:15:00PM +0200, Christian Ullrich wrote: > Hello all, > > I get the following output from pg_upgrade when trying to upgrade a > test cluster on Windows 7 x64: > > c:\Daten>path > PATH=c:\windows;c:\windows\system32;c:\Program Files\PostgreSQL\9.2\bin > > c:\Daten>pg_upgrade --old-bindir="c:\Program Files\PostgreSQL\9.1\bin" > --new-bindir="c:\Program Files\PostgreSQL\9.2\bin" > --old-datadir="c:\Daten\db\pgsql" > --new-datadir=c:\Daten\db\pgsql-9.2\data --old-port=5432 > --new-port=5433 --user=postgres --verbose --check So I assume this is an upgrade from 9.1 to 9.2, based on the prompts, right? > > [...] > > Checking for contrib/isn with bigint-passing mismatch ok > ""c:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -D > "c:\Daten\db\pgsql" -o "" stop >> "pg_upgrade_utility.log" 2>&1" Notice the -o "" above. I am confused how you could get that because looking at the 9.2.0 source code I see: snprintf(cmd, sizeof(cmd), "\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d %s %s%s\" start", ------- cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port, (cluster->controldata.cat_ver >= BINARY_UPGRADE_SERVER_FLAG_CAT_VER) ? "-b" : "-c autovacuum=off -c autovacuum_freeze_max_age=2000000000", cluster->pgopts ? cluster->pgopts : "", socket_string); Notice that -o always has at least "-p". Please tell use the server versions and where you got these binaries. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
* Bruce Momjian wrote: > On Thu, Sep 13, 2012 at 02:15:00PM +0200, Christian Ullrich wrote: >> c:\Daten>path >> PATH=c:\windows;c:\windows\system32;c:\Program Files\PostgreSQL\9.2\bin >> >> c:\Daten>pg_upgrade --old-bindir="c:\Program Files\PostgreSQL\9.1\bin" >> --new-bindir="c:\Program Files\PostgreSQL\9.2\bin" >> --old-datadir="c:\Daten\db\pgsql" >> --new-datadir=c:\Daten\db\pgsql-9.2\data --old-port=5432 >> --new-port=5433 --user=postgres --verbose --check > > So I assume this is an upgrade from 9.1 to 9.2, based on the prompts, > right? 9.1.5 to 9.2.0. And, as all to usual, I find myself apologizing for wasting everyone's time after finding my problem just after asking for help. It was my fault; while I'm too embarrassed to go into the details, let's just say there was an environmental discrepancy I had caused. -- Christian
On Thu, Sep 13, 2012 at 11:36:56PM +0200, Christian Ullrich wrote: > * Bruce Momjian wrote: > > >On Thu, Sep 13, 2012 at 02:15:00PM +0200, Christian Ullrich wrote: > > >>c:\Daten>path > >>PATH=c:\windows;c:\windows\system32;c:\Program Files\PostgreSQL\9.2\bin > >> > >>c:\Daten>pg_upgrade --old-bindir="c:\Program Files\PostgreSQL\9.1\bin" > >>--new-bindir="c:\Program Files\PostgreSQL\9.2\bin" > >>--old-datadir="c:\Daten\db\pgsql" > >>--new-datadir=c:\Daten\db\pgsql-9.2\data --old-port=5432 > >>--new-port=5433 --user=postgres --verbose --check > > > >So I assume this is an upgrade from 9.1 to 9.2, based on the prompts, > >right? > > 9.1.5 to 9.2.0. > > And, as all to usual, I find myself apologizing for wasting > everyone's time after finding my problem just after asking for help. > It was my fault; while I'm too embarrassed to go into the details, > let's just say there was an environmental discrepancy I had caused. OK. I would love to know how a misconfiguration would remove a text string from a command, but hey, as long as it is now working for you. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +