pg_upgrade and log file output on Windows
От | Bruce Momjian |
---|---|
Тема | pg_upgrade and log file output on Windows |
Дата | |
Msg-id | 201107190328.p6J3Sas21291@momjian.us обсуждение исходный текст |
Ответы |
Re: pg_upgrade and log file output on Windows
Re: pg_upgrade and log file output on Windows |
Список | pgsql-hackers |
Has anyone successfully used pg_upgrade 9.0 with -l (log) on Windows? I received a private email bug report that pg_upgrade 9.0 does not work with the -l/log option on Windows. The error is: Analyzing all rows in the new cluster""c:/MinGW/msys/1.0/home/edb/inst/bin/vacuumdb" --port 55445 --username "edb" --all--analyze>> c:/MinGW/msys/1.0/home/edb/auxschedule/test.log 2>&1"The process cannot access the file because it is beingused by anotherprocess. What has me confused is this same code exists in pg_migrator, which was fixed to work with -l on Windows by Hiroshi Saito with this change: /* * 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_ctloutput to 'nul'. */ sprintf(cmd, SYSTEMQUOTE "\"%s/pg_ctl\" -l \"%s\" -D \"%s\" " "-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 The fix was not to use the same log file and output file for pg_ctl. But as you can see, the pg_ctl and vacuumdb code is unchanged: prep_status(ctx, "Analyzing all rows in the new cluster"); exec_prog(ctx, true, SYSTEMQUOTE "\"%s/vacuumdb\"--port %d --username \"%s\" " "--all --analyze >> %s 2>&1" SYSTEMQUOTE, ctx->new.bindir,ctx->new.port, ctx->user, ctx->logfile); I can't figure out of there is something odd about this user's setup or if there is a bug in pg_upgrade with -l on Windows. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: