Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP - Mailing list pgsql-bugs
From | Edmund Horner |
---|---|
Subject | Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP |
Date | |
Msg-id | CAMyN-kBUzHrkHK77cCAU=VQvv7tT-ekXO+JJZTTBscNrzEct1g@mail.gmail.com Whole thread Raw |
In response to | Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP (Bruce Momjian <bruce@momjian.us>) |
Responses |
Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP
(Edmund Horner <ejrh00@gmail.com>)
Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP (Bruce Momjian <bruce@momjian.us>) |
List | pgsql-bugs |
On 25 May 2012 01:59, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, May 24, 2012 at 03:42:25PM +0200, Magnus Hagander wrote: >> I've built a new one off git master + Bruce's patch. You can get it >> from http://www.hagander.net/tmp/pg_upgrade.zip - please see if that >> one works for you. > > Thanks, but thinking more, I am more concerned. =A0Here is what we think > is happening (ah, flashbacks to the PG Windows port): > > =A0 =A0 =A0 =A0pg_ctl start > file1 > =A0 =A0 =A0 =A0pg_dumpall > file1 > =A0 =A0 =A0 =A0pg_ctl stop > file1 > > generates a file share error for pg_dump. =A0I have replaced that with: > > =A0 =A0 =A0 =A0pg_ctl start > file2 > =A0 =A0 =A0 =A0pg_dumpall > file1 > =A0 =A0 =A0 =A0pg_ctl stop > file2 > > I am now concerned that 'pg_ctl stop' is going to give us a share > violation. =A0The fix will be to use 'file3' for pg_ctl stop. =A0Can I get > an updated report to see if that is accurate? =A0Thanks. Hi Bruce and Magnus, I've run the new EXE. It makes further progress than the previous build, and creates the following files (with sizes): 158,142 pg_upgrade_dump_all.sql 157,127 pg_upgrade_dump_db.sql 993 pg_upgrade_dump_globals.sql 19,164 pg_upgrade_internal.log 179 pg_upgrade_restore.log 179 pg_upgrade_server.log 234 pg_upgrade_server2.log 43,476 pg_upgrade_utility.log It still fails (when run in verbose mode): Creating catalog dump ""c:\ehorner\pgsql\bin/pg_dumpall" --port 50432 --username "ehorner" --schema-only --binary-upgrade --verbose > "pg_upgrade_dump_all.sql" 2>> "pg_upgrade_utility.log"" ok ""c:\ehorner\pgsql-old\bin/pg_ctl" -w -l "pg_upgrade_server2.log" -D "c:\ehorner\pgdata-old" -o"" stop >> "pg_upgrade_server2.log" 2>&1" The process cannot access the file because it is being used by another process. *failure* There were problems executing """c:\ehorner\pgsql-old\bin/pg_ctl" -w -l "pg_upgrade_server2.log" -D "c:\ehorner\pgdata-old" -o "" stop >> "pg_upgrade_server2.log" 2>&1"" Consult the last few lines of "pg_upgrade_server2.log" for the probable cause of the failure. Failure, exiting ""c:\ehorner\pgsql-old\bin/pg_ctl" -w -l "pg_upgrade_server2.log" -D "c:\ehorner\pgdata-old" -o"" -m fast stop >> "pg_upgrade_server2.log" 2>&1" The process cannot access the file because it is being used by another process. *failure* There were problems executing """c:\ehorner\pgsql-old\bin/pg_ctl" -w -l "pg_upgrade_server2.log" -D "c:\ehorner\pgdata-old" -o "" -m fast stop >> "pg_upgrade_server2.log" 2>&1"" Consult the last few lines of "pg_upgrade_server2.log" for the probable cause of the failure. These messages are also in pg_upgrade_internal.log. pg_upgrade_server2.log simply says "waiting for server to start..... done" and "server started". There were some SHARING VIOLATIONs on pg_upgrade_server2.log. In fact it looks like it occurs twice to two different "cmd.exe" invocations -- I'm not sure if that's two distinct steps in the process, or a single step being automatically retried. It's a bit hard to correlate the sequence of file system calls with the pg_upgrade log outputs. 17185 11:15:09 a.m. pg_ctl.exe:106380 WRITE C:\pg_upgrade_server2.log SUCCESS Offset: 210 Length: 1 18901 11:15:11 a.m. pg_ctl.exe:106380 WRITE C:\pg_upgrade_server2.log SUCCESS Offset: 211 Length: 7 18904 11:15:11 a.m. pg_ctl.exe:106380 WRITE C:\pg_upgrade_server2.log SUCCESS Offset: 218 Length: 16 68104 11:15:38 a.m. cmd.exe:106096 OPEN C:\pg_upgrade_server2.log SHARING VIOLATION Options: Open Access: 0012019F 68105 11:15:38 a.m. cmd.exe:106096 OPEN C:\pg_upgrade_server2.log SHARING VIOLATION Options: OpenIf Access: 00120196 68696 11:15:38 a.m. cmd.exe:106104 OPEN C:\pg_upgrade_server2.log SHARING VIOLATION Options: Open Access: 0012019F 68697 11:15:38 a.m. cmd.exe:106104 OPEN C:\pg_upgrade_server2.log SHARING VIOLATION Options: OpenIf Access: 00120196 The offsets and lengths written by pg_ctl correpond to the last bits of text content in the file, which is: ----------------------------------------------------------------- pg_upgrade run on Fri May 25 11:27:02 2012 ----------------------------------------------------------------- waiting for server to start..... done server started I.e. I think pg_ctl wrote the last couple of lines, and then the two cmd.exe were unable to write anything more since presumably it's still open. So is this the problem you predicted above with pg_ctl stop? I'll provide the logs and filemon output privately if you need them.
pgsql-bugs by date: