Обсуждение: 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. +