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

Re: [Win32] Problem with rename()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "<Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, "<Magnus Hagander" <mha(at)sollentuna(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [Win32] Problem with rename()
Date: 2006-04-18 14:50:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-patches
"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> writes:
> LOG:  could not rename file "pg_xlog/000000010000010A000000BD" to
> "pg_xlog/000000010000010A000000D7", continuing to try
> ...
> Only one process (postgres.exe) is holding a handle to
> pg_xlog/000000010000010A000000BD:
> ...
> The second is similar, except that two postgres.exe processes (and
> nothing else) have the file open:

Hmm, could these be backends that have been sitting idle for some time?
I'd expect a backend to be holding open a handle for whichever WAL
segment it last wrote to.  If the backend sits idle for a couple of
checkpoints while others are advancing the end of WAL, then that segment
could become a target for renaming.

The only workable fix I can think of is to allow the checkpointer to
simply fail to rename this segment and go on about its business,
figuring that we'll be able to rename/delete the WAL segment in some
future checkpoint cycle.  Not sure how messy that would be to implement.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Ed L.Date: 2006-04-18 14:57:37
Subject: pre-existing shared memory block
Previous:From: Magnus HaganderDate: 2006-04-18 14:38:29
Subject: Re: [Win32] Problem with rename()

pgsql-patches by date

Next:From: Magnus HaganderDate: 2006-04-18 14:52:36
Subject: Re: Question on win32 semaphore simulation
Previous:From: Harald Armin MassaDate: 2006-04-18 14:35:19
Subject: Re: [Win32] Problem with rename()

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