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

Re: [Win32] Problem with rename()

From: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Bugs for PostgreSQL" <pgsql-bugs(at)postgreSQL(dot)org>,"PostgreSQL-patches" <pgsql-patches(at)postgreSQL(dot)org>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [Win32] Problem with rename()
Date: 2006-06-17 17:25:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-patches
>>> On 16.06.2006 at 23:21:21, in message
<200606162121(dot)k5GLLLw13054(at)candle(dot)pha(dot)pa(dot)us>, Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Yea.  Where you using WAL archiving?  We will have a fix in 8.1.5 to
> prevent multiple archivers from starting.  Perhaps that was a cause.
Not at the time, no.  The rename in question was just a regular WAL
segment rename.

> Yes, I just reread that thread.  I also am confused where to go from
> here.
Yeah, it's unfortunate that our best theory (a _commit on a deleted
file) just didn't seem to be supported by the evidence.  Although the
servers which see a heavy SELECT load are now Linux, we still have a
couple of Windows servers receiving the normal replication traffic.  We
still get regular fsync errors after the scheduled CLUSTERs so if you do
find a fix (or come up with a new theory), there's a test bed there (at
least for now).

> Were you the only one use Win32 in heavy usage?  You were on Win2003.

> Were there some bugs in the OS that got fixed later.
> Yep.  What has me baffled is why no one else is seeing the problem.
> We had a rash of reports, and now all is quiet.
We might be somewhat more susceptible than most too.  Due to the way
our middle tier parcels out queries, some connections might sit idle for
a long time.  Per Tom's explanation in the original thread, this is an
important factor.  Ultimately if a concurrent rename isn't possible in
Windows (and that looks likely), it's going to be a problem as things
stand now.


In response to

pgsql-bugs by date

Next:From: Devrim GUNDUZDate: 2006-06-17 21:43:01
Subject: 7.4.13 initdb fails on Turkish locale
Previous:From: Magnus HaganderDate: 2006-06-17 12:51:18
Subject: Re: BUG #2484: pg_dump not support < redirect

pgsql-patches by date

Next:From: Tom LaneDate: 2006-06-17 17:43:06
Subject: Re: Test request for Stats collector performance improvement
Previous:From: Tom LaneDate: 2006-06-17 15:47:46
Subject: Re: plpython improvements

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