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:

Previous
From: Jeff Frost
Date:
Subject: Re: 9.1.3 backends getting stuck in 'startup'
Next
From: Edmund Horner
Date:
Subject: Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP