Обсуждение: Testing 9.0beta3 and pg_upgrade
Hi,
I'm trying pg_upgrade on my Windows installation and I have two suggestions for the manual regarding pg_upgrade:
When specifying directories, pg_upgrade *requires* a forward slash as the path separator. This is (still) uncommon in
theWindows world (although Windows does support it) and even though the example in the manual does show forward
slashes,I think it would be a good idea to specifically mention the fact that it will *not* work with a backslash.
Actually the error message when you do so is a bit misleading as well ("You must identify the directory where the old
clusterbinaries reside") even though the paramter is there.
After I sorted that out I ran pg_upgrade and it failed somewhere in the middle:
------ snip
C:\etc\pg90-beta3>C:\etc\pg90-beta3\pgsql\bin\pg_upgrade.exe --user=postgres --old-datadir
"c:/Daten/db/pgdata84/" -
-old-bindir "c:/Programme/PostgreSQL/8.4/bin/" --new-datadir "c:/etc/pg90-beta3/datadir/"
--new-port=5434 --new-bind
ir "C:\etc\pg90-beta3\pgsql\bin"
Performing Consistency Checks
-----------------------------
Checking old data directory (c:/Daten/db/pgdata84) ok
Checking new data directory (c:/etc/pg90-beta3/datadir) ok
Checking for /contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Creating catalog dump ok
Checking for presence of required libraries ok
| If pg_upgrade fails after this point, you must
| re-initdb the new cluster before continuing.
| You will also need to remove the ".old" suffix
| from c:/Daten/db/pgdata84/global/pg_control.old.
Performing Migration
--------------------
Adding ".old" suffix to old global/pg_control ok
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting new commit clogs ok
Copying old commit clogs to new server 1 Datei(en) kopiert
ok
Setting next transaction id for new cluster ok
Resetting WAL archives ok
Setting frozenxid counters in new cluster ok
Creating databases in the new cluster psql:C:/etc/pg90-beta3/pg_upgrade_dump_globals.sql:29:
ERROR: CREATE DATABASE c
annot run inside a transaction block
There were problems executing ""C:\etc\pg90-beta3\pgsql\bin/psql" --port 5434 --username "postgres" --set
ON_ERROR_STOP=on-f "C:\etc\pg90-b
eta3/pg_upgrade_dump_globals.sql" --dbname template1 >> "nul""
------ end of console output --------
The "cannot run inside a transaction block" rang a bell, and once I removed "\set AUTOCOMMIT off" from my psqlrc.conf,
pg_upgradewent through without problems.
I would suggest to either manually change the autocommit mode from within pg_upgrade or to add a note in the manual to
disable/removethis setting from psqlrc.conf before running pg_upgrade. Personally I think the first option would be the
betterone.
Regards
Thomas
On 13/07/10 05:29, Thomas Kellerer wrote: > I would suggest to either manually change the autocommit mode from > within pg_upgrade or to add a note in the manual to disable/remove this > setting from psqlrc.conf before running pg_upgrade. Personally I think > the first option would be the better one. Should pg_upgrade be reading psqlrc at all? There are bound to be all sorts of exciting issues that psqlrc settings can create. -- Craig Ringer Tech-related writing: http://soapyfrogs.blogspot.com/
Craig Ringer, 13.07.2010 05:11: > On 13/07/10 05:29, Thomas Kellerer wrote: > >> I would suggest to either manually change the autocommit mode from >> within pg_upgrade or to add a note in the manual to disable/remove this >> setting from psqlrc.conf before running pg_upgrade. Personally I think >> the first option would be the better one. > > Should pg_upgrade be reading psqlrc at all? There are bound to be all > sorts of exciting issues that psqlrc settings can create. > I interpret the error message such that pg_upgrade _calls_ (i.e spawns) psql to run the CREATE DATABASE command. If thatis true, probably the easiest solution would be to run psql using the -X switch. Regards Thomas
Thomas Kellerer, 12.07.2010 23:29: > Hi, > > I'm trying pg_upgrade on my Windows installation and I have two > suggestions for the manual regarding pg_upgrade: > > When specifying directories, pg_upgrade *requires* a forward slash as > the path separator. This is (still) uncommon in the Windows world > (although Windows does support it) and even though the example in the > manual does show forward slashes, I think it would be a good idea to > specifically mention the fact that it will *not* work with a backslash. There is another misleading error message. When the old *bin*dir is not specified correctly, pg_upgrade claims the old *data*dir does not exist Something like: pg_upgrade --check --old-bindir="c:/Program Files/PostgreSQL/8.4" .... (note the missing /bin part) will cause the following output: 'c:/Program' is not recognized as an internal or external command, operable program or batch file. Performing Consistency Checks ----------------------------- Checking old data directory (c:/Daten/db/pgdata84) check for postgres failed - No such file or directory It took me a while to find out that the bindir was wrong, not the datadir. The "c:/Program' is not recognized as an.." madeit even more confusing. Regards Thomas
Thomas Kellerer, 12.07.2010 23:29:
> Hi,
>
> I'm trying pg_upgrade on my Windows installation and I have two
> suggestions for the manual regarding pg_upgrade:
>
I found another problem and I'm not sure if this is a bug or a user error :)
My batch file to start pg_upgrade looks like this:
%~dp0server\bin\pg_upgrade ^
--check ^
--old-bindir="c:/Program Files/PostgreSQL/8.4/bin" ^
--new-bindir="c:/etc/Postgres9.0-beta3/server/bin" ^
--old-datadir="c:/Daten/db/pgdata84" ^
--new-datadir="c:/etc/Postgres9.0-beta3/datadir" ^
--user=postgres ^
--logfile=migrate.log ^
--verbose
with these settings pg_upgrade fails to start the old server.
On the console I can see:
Checking new data directory (c:/etc/Postgres9.0-beta3/datadir)ok
""c:/Program Files/PostgreSQL/8.4/bin/pg_ctl" -l "migrate.log" -D "c:/Daten/db/pgdata84" -o "-p 5432 -c autovacuum=off
-cautovacuum_freeze_max_age=20
00000000" start >> "nul" 2>&1"
Trying to start old server ...........
Unable to start old postmaster with the command: ""c:/Program Files/PostgreSQL/8.4/bin/pg_ctl" -l "migrate.log" -D
"c:/Daten/db/pgdata84"-o "-p 5432
-c autovacuum=off -c autovacuum_freeze_max_age=2000000000" start >> "nul" 2>&1"
Perhaps pg_hba.conf was not set to "trust".
Now when I manually copy and paste the logged command, the server starts up fine and I can verify with ProcessExplorer
thatpg_upgrade indeed does not spawn a postgres.exe (or pg_ctl.exe)
As I have done one successful migration already, and the only difference was the logfile, I removed the --logfile
switchfrom the batch file and then pg_upgrade ran without problems.
In the commandline starting the old server -l "migrate.log" is replaced with -l "nul"
I _think_ the reason for this is that pg_upgrade locks migrate.log and then postgres.exe cannot write to the file and
thusfails to start.
When I manually run the command, pg_upgrade is not locking migrate.log and therefor the server starts (and thus the
confusionthat the same command works from the commandline but not when pg_upgrade runs it)
Regards
Thomas
P.S.: pg_upgrade --help says: "Report bugs to <pg-migrator-general@lists.pgfoundry.org>"
Shouldn't that be changed as well?
Thomas Kellerer wrote: > Hi, > > I'm trying pg_upgrade on my Windows installation and I have two > suggestions for the manual regarding pg_upgrade: > > When specifying directories, pg_upgrade *requires* a forward slash as > the path separator. This is (still) uncommon in the Windows world > (although Windows does support it) and even though the example in the > manual does show forward slashes, I think it would be a good idea to > specifically mention the fact that it will *not* work with a backslash. Are you sure this is not the behavior of all Postgres commands? For example, if you use 'psql -f filename dbname', does 'filename' have the same behavior as the pg_upgrade directory specifications? > The "cannot run inside a transaction block" rang a bell, and once I > removed "\set AUTOCOMMIT off" from my psqlrc.conf, pg_upgrade went > through without problems. > > I would suggest to either manually change the autocommit mode from > within pg_upgrade or to add a note in the manual to disable/remove this > setting from psqlrc.conf before running pg_upgrade. Personally I think > the first option would be the better one. I have applied the attached patch so .psqlrc is no longer read by psql. That should fix this problem. I can't imagine anything pg_upgrade needs in .pgsqlrc. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: contrib/pg_upgrade/check.c =================================================================== RCS file: /cvsroot/pgsql/contrib/pg_upgrade/check.c,v retrieving revision 1.11 diff -c -c -r1.11 check.c *** contrib/pg_upgrade/check.c 6 Jul 2010 19:18:55 -0000 1.11 --- contrib/pg_upgrade/check.c 13 Jul 2010 15:56:43 -0000 *************** *** 152,160 **** { prep_status(ctx, "Adjusting sequences"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --set ON_ERROR_STOP=on --port %d " ! "--username \"%s\" -f \"%s\" --dbname template1 >> \"%s\"" ! SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, sequence_script_file_name, ctx->logfile); unlink(sequence_script_file_name); --- 152,160 ---- { prep_status(ctx, "Adjusting sequences"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --set ON_ERROR_STOP=on " ! "--no-psqlrc --port %d --username \"%s\" " ! "-f \"%s\" --dbname template1 >> \"%s\"" SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, sequence_script_file_name, ctx->logfile); unlink(sequence_script_file_name); Index: contrib/pg_upgrade/pg_upgrade.c =================================================================== RCS file: /cvsroot/pgsql/contrib/pg_upgrade/pg_upgrade.c,v retrieving revision 1.10 diff -c -c -r1.10 pg_upgrade.c *** contrib/pg_upgrade/pg_upgrade.c 6 Jul 2010 19:18:55 -0000 1.10 --- contrib/pg_upgrade/pg_upgrade.c 13 Jul 2010 15:56:43 -0000 *************** *** 202,210 **** */ prep_status(ctx, "Creating databases in the new cluster"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --port %d --username \"%s\" " ! "--set ON_ERROR_STOP=on -f \"%s/%s\" --dbname template1 >> \"%s\"" ! SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, ctx->cwd, GLOBALS_DUMP_FILE, ctx->logfile); check_ok(ctx); --- 202,211 ---- */ prep_status(ctx, "Creating databases in the new cluster"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --set ON_ERROR_STOP=on " ! /* --no-psqlrc prevents AUTOCOMMIT=off */ ! "--no-psqlrc --port %d --username \"%s\" " ! "-f \"%s/%s\" --dbname template1 >> \"%s\"" SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, ctx->cwd, GLOBALS_DUMP_FILE, ctx->logfile); check_ok(ctx); *************** *** 225,233 **** prep_status(ctx, "Restoring database schema to new cluster"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --port %d --username \"%s\" " ! "--set ON_ERROR_STOP=on -f \"%s/%s\" --dbname template1 >> \"%s\"" ! SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, ctx->cwd, DB_DUMP_FILE, ctx->logfile); check_ok(ctx); --- 226,234 ---- prep_status(ctx, "Restoring database schema to new cluster"); exec_prog(ctx, true, ! SYSTEMQUOTE "\"%s/psql\" --set ON_ERROR_STOP=on " ! "--no-psqlrc --port %d --username \"%s\" " ! "-f \"%s/%s\" --dbname template1 >> \"%s\"" SYSTEMQUOTE, ctx->new.bindir, ctx->new.port, ctx->user, ctx->cwd, DB_DUMP_FILE, ctx->logfile); check_ok(ctx);
Thomas Kellerer wrote: > Craig Ringer, 13.07.2010 05:11: > > On 13/07/10 05:29, Thomas Kellerer wrote: > > > >> I would suggest to either manually change the autocommit mode from > >> within pg_upgrade or to add a note in the manual to disable/remove this > >> setting from psqlrc.conf before running pg_upgrade. Personally I think > >> the first option would be the better one. > > > > Should pg_upgrade be reading psqlrc at all? There are bound to be all > > sorts of exciting issues that psqlrc settings can create. > > > I interpret the error message such that pg_upgrade _calls_ (i.e spawns) > psql to run the CREATE DATABASE command. If that is true, probably the > easiest solution would be to run psql using the -X switch. Yes, this is the solution I used. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
Thomas Kellerer wrote: > Thomas Kellerer, 12.07.2010 23:29: > > Hi, > > > > I'm trying pg_upgrade on my Windows installation and I have two > > suggestions for the manual regarding pg_upgrade: > > > > When specifying directories, pg_upgrade *requires* a forward slash as > > the path separator. This is (still) uncommon in the Windows world > > (although Windows does support it) and even though the example in the > > manual does show forward slashes, I think it would be a good idea to > > specifically mention the fact that it will *not* work with a backslash. > > There is another misleading error message. > > When the old *bin*dir is not specified correctly, pg_upgrade claims the old *data*dir does not exist > > Something like: > > pg_upgrade --check --old-bindir="c:/Program Files/PostgreSQL/8.4" .... > > (note the missing /bin part) > > will cause the following output: > > 'c:/Program' is not recognized as an internal or external command, > operable program or batch file. > Performing Consistency Checks > ----------------------------- > Checking old data directory (c:/Daten/db/pgdata84) > check for postgres failed - No such file or directory > > It took me a while to find out that the bindir was wrong, not the datadir. The "c:/Program' is not recognized as an.."made it even more confusing. OK, I have modified pg_upgrade with the attachd patch that reports /bin and /data directory tests separately. Thanks for the report. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: contrib/pg_upgrade/exec.c =================================================================== RCS file: /cvsroot/pgsql/contrib/pg_upgrade/exec.c,v retrieving revision 1.8 diff -c -c -r1.8 exec.c *** contrib/pg_upgrade/exec.c 6 Jul 2010 19:18:55 -0000 1.8 --- contrib/pg_upgrade/exec.c 13 Jul 2010 17:59:33 -0000 *************** *** 13,22 **** #include <grp.h> ! static void checkBinDir(migratorContext *ctx, ClusterInfo *cluster); static int check_exec(migratorContext *ctx, const char *dir, const char *cmdName); static const char *validate_exec(const char *path); - static int check_data_dir(migratorContext *ctx, const char *pg_data); /* --- 13,22 ---- #include <grp.h> ! static void check_data_dir(migratorContext *ctx, const char *pg_data); ! static void check_bin_dir(migratorContext *ctx, ClusterInfo *cluster); static int check_exec(migratorContext *ctx, const char *dir, const char *cmdName); static const char *validate_exec(const char *path); /* *************** *** 56,61 **** --- 56,89 ---- /* + * is_server_running() + * + * checks whether postmaster on the given data directory is running or not. + * The check is performed by looking for the existence of postmaster.pid file. + */ + bool + is_server_running(migratorContext *ctx, const char *datadir) + { + char path[MAXPGPATH]; + int fd; + + snprintf(path, sizeof(path), "%s/postmaster.pid", datadir); + + if ((fd = open(path, O_RDONLY, 0)) < 0) + { + if (errno != ENOENT) + pg_log(ctx, PG_FATAL, "\ncould not open file \"%s\" for reading\n", + path); + + return false; + } + + close(fd); + return true; + } + + + /* * verify_directories() * * does all the hectic work of verifying directories and executables *************** *** 67,87 **** verify_directories(migratorContext *ctx) { prep_status(ctx, "Checking old data directory (%s)", ctx->old.pgdata); ! if (check_data_dir(ctx, ctx->old.pgdata) != 0) ! pg_log(ctx, PG_FATAL, "Failed\n"); ! checkBinDir(ctx, &ctx->old); check_ok(ctx); prep_status(ctx, "Checking new data directory (%s)", ctx->new.pgdata); ! if (check_data_dir(ctx, ctx->new.pgdata) != 0) ! pg_log(ctx, PG_FATAL, "Failed\n"); ! checkBinDir(ctx, &ctx->new); check_ok(ctx); } /* ! * checkBinDir() * * This function searches for the executables that we expect to find * in the binaries directory. If we find that a required executable --- 95,156 ---- verify_directories(migratorContext *ctx) { prep_status(ctx, "Checking old data directory (%s)", ctx->old.pgdata); ! check_data_dir(ctx, ctx->old.pgdata); ! check_ok(ctx); ! ! prep_status(ctx, "Checking old bin directory (%s)", ctx->old.bindir); ! check_bin_dir(ctx, &ctx->old); check_ok(ctx); prep_status(ctx, "Checking new data directory (%s)", ctx->new.pgdata); ! check_data_dir(ctx, ctx->new.pgdata); ! check_ok(ctx); ! ! prep_status(ctx, "Checking new bin directory (%s)", ctx->new.bindir); ! check_bin_dir(ctx, &ctx->new); check_ok(ctx); } /* ! * check_data_dir() ! * ! * This function validates the given cluster directory - we search for a ! * small set of subdirectories that we expect to find in a valid $PGDATA ! * directory. If any of the subdirectories are missing (or secured against ! * us) we display an error message and exit() ! * ! */ ! static void ! check_data_dir(migratorContext *ctx, const char *pg_data) ! { ! char subDirName[MAXPGPATH]; ! int subdirnum; ! const char *requiredSubdirs[] = {"base", "global", "pg_clog", ! "pg_multixact", "pg_subtrans", "pg_tblspc", "pg_twophase", ! "pg_xlog"}; ! ! for (subdirnum = 0; ! subdirnum < sizeof(requiredSubdirs) / sizeof(requiredSubdirs[0]); ! ++subdirnum) ! { ! struct stat statBuf; ! ! snprintf(subDirName, sizeof(subDirName), "%s/%s", pg_data, ! requiredSubdirs[subdirnum]); ! ! if (stat(subDirName, &statBuf) != 0) ! report_status(ctx, PG_FATAL, "check for %s failed: %s", ! requiredSubdirs[subdirnum], getErrorText(errno)); ! else if (!S_ISDIR(statBuf.st_mode)) ! report_status(ctx, PG_FATAL, "%s is not a directory", ! requiredSubdirs[subdirnum]); ! } ! } ! ! ! /* ! * check_bin_dir() * * This function searches for the executables that we expect to find * in the binaries directory. If we find that a required executable *************** *** 89,95 **** * exit(). */ static void ! checkBinDir(migratorContext *ctx, ClusterInfo *cluster) { check_exec(ctx, cluster->bindir, "postgres"); check_exec(ctx, cluster->bindir, "psql"); --- 158,164 ---- * exit(). */ static void ! check_bin_dir(migratorContext *ctx, ClusterInfo *cluster) { check_exec(ctx, cluster->bindir, "postgres"); check_exec(ctx, cluster->bindir, "psql"); *************** *** 99,132 **** /* - * is_server_running() - * - * checks whether postmaster on the given data directory is running or not. - * The check is performed by looking for the existence of postmaster.pid file. - */ - bool - is_server_running(migratorContext *ctx, const char *datadir) - { - char path[MAXPGPATH]; - int fd; - - snprintf(path, sizeof(path), "%s/postmaster.pid", datadir); - - if ((fd = open(path, O_RDONLY, 0)) < 0) - { - if (errno != ENOENT) - pg_log(ctx, PG_FATAL, "\ncould not open file \"%s\" for reading\n", - path); - - return false; - } - - close(fd); - return true; - } - - - /* * check_exec() * * Checks whether either of the two command names (cmdName and alternative) --- 168,173 ---- *************** *** 264,313 **** return NULL; #endif } - - - /* - * check_data_dir() - * - * This function validates the given cluster directory - we search for a - * small set of subdirectories that we expect to find in a valid $PGDATA - * directory. If any of the subdirectories are missing (or secured against - * us) we display an error message and exit() - * - */ - static int - check_data_dir(migratorContext *ctx, const char *pg_data) - { - char subDirName[MAXPGPATH]; - const char *requiredSubdirs[] = {"base", "global", "pg_clog", - "pg_multixact", "pg_subtrans", - "pg_tblspc", "pg_twophase", "pg_xlog"}; - bool fail = false; - int subdirnum; - - for (subdirnum = 0; subdirnum < sizeof(requiredSubdirs) / sizeof(requiredSubdirs[0]); ++subdirnum) - { - struct stat statBuf; - - snprintf(subDirName, sizeof(subDirName), "%s/%s", pg_data, - requiredSubdirs[subdirnum]); - - if ((stat(subDirName, &statBuf)) != 0) - { - report_status(ctx, PG_WARNING, "check for %s warning: %s", - requiredSubdirs[subdirnum], getErrorText(errno)); - fail = true; - } - else - { - if (!S_ISDIR(statBuf.st_mode)) - { - report_status(ctx, PG_WARNING, "%s is not a directory", - requiredSubdirs[subdirnum]); - fail = true; - } - } - } - - return (fail) ? -1 : 0; - } --- 305,307 ----
Thomas Kellerer wrote: > Checking new data directory (c:/etc/Postgres9.0-beta3/datadir)ok > ""c:/Program Files/PostgreSQL/8.4/bin/pg_ctl" -l "migrate.log" -D > "c:/Daten/db/pgdata84" -o "-p 5432 -c autovacuum=off -c > autovacuum_freeze_max_age=20 00000000" start >> "nul" 2>&1" Trying to > start old server ........... > Unable to start old postmaster with the command: ""c:/Program > Files/PostgreSQL/8.4/bin/pg_ctl" -l "migrate.log" -D > "c:/Daten/db/pgdata84" -o "-p 5432 -c autovacuum=off -c > autovacuum_freeze_max_age=2000000000" start >> "nul" 2>&1" Perhaps > pg_hba.conf was not set to "trust". > > Now when I manually copy and paste the logged command, the server starts > up fine and I can verify with ProcessExplorer that pg_upgrade indeed > does not spawn a postgres.exe (or pg_ctl.exe) > > As I have done one successful migration already, and the only difference > was the logfile, I removed the --logfile switch from the batch file > and then pg_upgrade ran without problems. > > In the commandline starting the old server -l "migrate.log" is replaced > with -l "nul" > I _think_ the reason for this is that pg_upgrade locks migrate.log and > then postgres.exe cannot write to the file and thus fails to start. > When I manually run the command, pg_upgrade is not locking migrate.log > and therefor the server starts (and thus the confusion that the same > command works from the commandline but not when pg_upgrade runs it) Your diagnosis is correct. I thought we had fixed this by having pg_ctl output go to NUL, but it turns out even server logs can't go to nul either if we are already logging to that file. Attached patch removes logging of pg_ctl and server output on win32. > P.S.: pg_upgrade --help says: "Report bugs to > <pg-migrator-general@lists.pgfoundry.org>" Shouldn't that be changed > as well? Oops, fixed as well. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + Index: contrib/pg_upgrade/server.c =================================================================== RCS file: /cvsroot/pgsql/contrib/pg_upgrade/server.c,v retrieving revision 1.8 diff -c -c -r1.8 server.c *** contrib/pg_upgrade/server.c 6 Jul 2010 19:18:55 -0000 1.8 --- contrib/pg_upgrade/server.c 13 Jul 2010 20:00:41 -0000 *************** *** 181,189 **** } /* ! * On Win32, we can't send both server output and pg_ctl output to the * same file because we get the error: "The process cannot access the file ! * because it is being used by another process." so we have to send pg_ctl * output to 'nul'. */ snprintf(cmd, sizeof(cmd), --- 181,189 ---- } /* ! * On Win32, we can't send both pg_upgrade output and pg_ctl output to the * same file because we get the error: "The process cannot access the file ! * because it is being used by another process." so we have to send all other * output to 'nul'. */ snprintf(cmd, sizeof(cmd), *************** *** 191,201 **** "-o \"-p %d -c autovacuum=off " "-c autovacuum_freeze_max_age=2000000000\" " "start >> \"%s\" 2>&1" SYSTEMQUOTE, ! bindir, ctx->logfile, datadir, port, #ifndef WIN32 ! ctx->logfile); #else ! DEVNULL); #endif exec_prog(ctx, true, "%s", cmd); --- 191,201 ---- "-o \"-p %d -c autovacuum=off " "-c autovacuum_freeze_max_age=2000000000\" " "start >> \"%s\" 2>&1" SYSTEMQUOTE, ! bindir, #ifndef WIN32 ! ctx->logfile, datadir, port, ctx->logfile); #else ! DEVNULL, datadir, port, DEVNULL); #endif exec_prog(ctx, true, "%s", cmd); *************** *** 235,245 **** snprintf(cmd, sizeof(cmd), SYSTEMQUOTE "\"%s/pg_ctl\" -l \"%s\" -D \"%s\" %s stop >> " "\"%s\" 2>&1" SYSTEMQUOTE, ! bindir, ctx->logfile, datadir, fast ? "-m fast" : "", #ifndef WIN32 ! ctx->logfile); #else ! DEVNULL); #endif exec_prog(ctx, fast ? false : true, "%s", cmd); --- 235,245 ---- snprintf(cmd, sizeof(cmd), SYSTEMQUOTE "\"%s/pg_ctl\" -l \"%s\" -D \"%s\" %s stop >> " "\"%s\" 2>&1" SYSTEMQUOTE, ! bindir, #ifndef WIN32 ! ctx->logfile, datadir, fast ? "-m fast" : "", ctx->logfile); #else ! DEVNULL, datadir, fast ? "-m fast" : "", DEVNULL); #endif exec_prog(ctx, fast ? false : true, "%s", cmd); Index: contrib/pg_upgrade/server.c =================================================================== RCS file: /cvsroot/pgsql/contrib/pg_upgrade/server.c,v retrieving revision 1.8 diff -c -c -r1.8 server.c *** contrib/pg_upgrade/server.c 6 Jul 2010 19:18:55 -0000 1.8 --- contrib/pg_upgrade/server.c 13 Jul 2010 20:00:41 -0000 *************** *** 181,189 **** } /* ! * On Win32, we can't send both server output and pg_ctl output to the * same file because we get the error: "The process cannot access the file ! * because it is being used by another process." so we have to send pg_ctl * output to 'nul'. */ snprintf(cmd, sizeof(cmd), --- 181,189 ---- } /* ! * On Win32, we can't send both pg_upgrade output and pg_ctl output to the * same file because we get the error: "The process cannot access the file ! * because it is being used by another process." so we have to send all other * output to 'nul'. */ snprintf(cmd, sizeof(cmd), *************** *** 191,201 **** "-o \"-p %d -c autovacuum=off " "-c autovacuum_freeze_max_age=2000000000\" " "start >> \"%s\" 2>&1" SYSTEMQUOTE, ! bindir, ctx->logfile, datadir, port, #ifndef WIN32 ! ctx->logfile); #else ! DEVNULL); #endif exec_prog(ctx, true, "%s", cmd); --- 191,201 ---- "-o \"-p %d -c autovacuum=off " "-c autovacuum_freeze_max_age=2000000000\" " "start >> \"%s\" 2>&1" SYSTEMQUOTE, ! bindir, #ifndef WIN32 ! ctx->logfile, datadir, port, ctx->logfile); #else ! DEVNULL, datadir, port, DEVNULL); #endif exec_prog(ctx, true, "%s", cmd); *************** *** 235,245 **** snprintf(cmd, sizeof(cmd), SYSTEMQUOTE "\"%s/pg_ctl\" -l \"%s\" -D \"%s\" %s stop >> " "\"%s\" 2>&1" SYSTEMQUOTE, ! bindir, ctx->logfile, datadir, fast ? "-m fast" : "", #ifndef WIN32 ! ctx->logfile); #else ! DEVNULL); #endif exec_prog(ctx, fast ? false : true, "%s", cmd); --- 235,245 ---- snprintf(cmd, sizeof(cmd), SYSTEMQUOTE "\"%s/pg_ctl\" -l \"%s\" -D \"%s\" %s stop >> " "\"%s\" 2>&1" SYSTEMQUOTE, ! bindir, #ifndef WIN32 ! ctx->logfile, datadir, fast ? "-m fast" : "", ctx->logfile); #else ! DEVNULL, datadir, fast ? "-m fast" : "", DEVNULL); #endif exec_prog(ctx, fast ? false : true, "%s", cmd);