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: 13220.1145371858@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-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

Responses

Browse pgsql-bugs by date

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

Browse pgsql-patches by date

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