Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP - Mailing list pgsql-bugs
From | Bruce Momjian |
---|---|
Subject | Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP |
Date | |
Msg-id | 20120524003302.GF10306@momjian.us Whole thread Raw |
In response to | Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP (Magnus Hagander <magnus@hagander.net>) |
Responses |
Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP
(Edmund Horner <ejrh00@gmail.com>)
|
List | pgsql-bugs |
On Wed, May 23, 2012 at 03:20:30PM +0200, Magnus Hagander wrote: > On Wed, May 23, 2012 at 5:50 AM, Edmund Horner <ejrh00@gmail.com> wrote: > > On 22 May 2012 18:49, Craig Ringer <ringerc@ringerc.id.au> wrote: > >> When you shut down the 9.1.3 cluster did you make absolutely certain there > >> were no postgres.exe processes lurking around when you tested? Given the > >> incredible thouroughness of your report I imagine you did, but it's worth > >> checking, as a lingering `postgres.exe' could (I imagine) cause such an > >> issue. Not that it should ever happen. > > > > Yes, I ensured there were no postgres.exe processes running before > > running up_upgrade. On a related note, postgres.exe processes DO > > remaining running after pg_upgrade fails with this error. Not sure if > > they're from the old or new binaries. I generally terminate them and > > recreate the destination cluster between retries. Additionally, the > > old cluster needs to be cycled: start it, and then stop it; because > > the next pg_upgrade run thinks a postgres.exe could still be using it. > > pg_ctl start also prints a warning about this but starts anyway. > > > >> Do you have the option of re-trying with your AV disabled or removed? > > > > At work I can't tamper with the AV, but I can run pg_upgrade in a > > directory that is excluded from AV (the c:\ccviews directory used by > > Clearcase!). > > > > The log files are created there, and there is no AV activity on them > > according to Filemon. There is still a SHARING VIOLATION on > > pg_upgrade_utility.log, though: > > This certainly looks like both pg_ctl and whatever is running under > cmd are both accessing the same logfile. This won't work. We can make > pg_ctl open it in sharing mode, but I'm pretty sure there is nothing > we can do about CMD - I assume that's coming from a shell redirect > somewhere? > > > 142 3:47:47 p.m. pg_ctl.exe:98832 WRITE > > C:\ccviews\pg_upgrade_utility.log SUCCESS Offset: 396 Length: 16 > > 183 3:48:01 p.m. cmd.exe:99396 OPEN C:\ccviews\pg_upgrade_utility.log SHARING > > VIOLATION Options: Open Access: 0012019F > > We probably need to send these to different logfiles. Bruce? I have applied the attached patch which should fix the problem. How can we get Edmund a copy of a new binary for testing? Does he have to wait for beta2? In pre-9.2, pg_ctl output was sent to /dev/null to avoid this problem, but that was to avoid sending pg_ctl -l output and stdout output to the same file. With 9.2, now that we have multiple output files, I sent the pg_ctl stdout to the utility file. One would think that doing: pg_ctl -l file1 > file2 vacuumedb > file2 would not be a problem, but Edmund is reporting he is getting a file share error. It sounds like even though pg_ctl has finished, it still has the file open, perhaps by the still-running postmaster. I am unclear if the 'pg_ctl.exe' reported by the tool above is really pg_ctl or the postmaster. Anyway, I am pretty sure this patch fixes the problem, and I added a C comment explaining what I think is happening, but it isn't totally clear to me yet. It would be interesting to see the kept log files if pg_upgrade is run with the --retain flag. (Edmund, you can email those to me privately.) That would tell me what stage is causing the problem. The pg_upgrade output reported seems to indicate it is pg_dumpall: Creating catalog dump The process cannot access the file because it is being used by another process. *failure* which supports my idea that it is really the postmaster who has that file kept open and causing the share violation. In pre-9.2, we only output one log file, but now that we output 4, outputting one more on Windows for pg_ctl isn't a problem. My patch also adjusts the output file array now that is of variable size. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Attachment
pgsql-bugs by date: