Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Edmund Horner <ejrh00(at)gmail(dot)com>
Cc: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, pgsql-bugs(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP
Date: 2012-05-23 13:20:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Wed, May 23, 2012 at 5:50 AM, Edmund Horner <ejrh00(at)gmail(dot)com> wrote:
> On 22 May 2012 18:49, Craig Ringer <ringerc(at)ringerc(dot)id(dot)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

> 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?

 Magnus Hagander

In response to


pgsql-bugs by date

Next:From: Andres FreundDate: 2012-05-23 16:27:48
Subject: Re: BUG #6661: out-of-order XID insertion in KnownAssignedXids
Previous:From: Valentine GogichashviliDate: 2012-05-23 10:30:31
Subject: Re: BUG #6661: out-of-order XID insertion in KnownAssignedXids

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group