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
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() |
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() |