Re: [Win32] Problem with rename()

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>, "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>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [Win32] Problem with rename()
Date: 2006-04-18 14:38:29
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA352B8@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Ok. So we're obviously blocking ourselves out.

Which process was the stalled one? Was it the same one that held the
file open, or a different one?

Looking at our code, we have the comment:
/* These flags allow concurrent rename/unlink */
(FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE),

But I'm not sure that those flags actually guarantee that. They do allow
concurrent unlink, but not necessarily rename. I read elsewhere that it
should work, but can't find backing docs on MSDN. Seems it works in most
cases, but perhaps there are some where it doesn't?

Is there any way we can force our own other backends to close a file?
That would be an easy fix - have the postmaster tell all other backends
to close all files and reopen...

/Magnus

> -----Original Message-----
> From: Peter Brant [mailto:Peter(dot)Brant(at)wicourts(dot)gov]
> Sent: Tuesday, April 18, 2006 4:15 PM
> To: Bruce Momjian; Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu;
> Magnus Hagander <mha(at)sollentuna(dot)net
> Cc: pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] [Win32] Problem with rename()
>
> Unfortunately, it's not that simple. It would be
> straightforward to track down if it were.
>
> In response to other questions:
>
> It's Postgres 8.1.3 running on Windows 2003 Server. No
> anti-virus software is installed. The servers are
> essentially bare except for the OS and Postgres.
>
> We have "handle -a" output from two occurrences (different servers):
>
> For the first one:
>
> 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:
>
> F84: Event \BaseNamedObjects\pgident: postgres: bigbird
> bigbird 127.0.0.1(3306) BIND
> FF4: File G:\pgsql\data\pg_xlog\000000010000010A000000BD
>
> Nothing has the target file open.
>
> The second is similar, except that two postgres.exe processes
> (and nothing else) have the file open:
>
> LOG: could not rename file
> "pg_xlog/000000010000010A0000006E" to
> "pg_xlog/000000010000010A00000087", continuing to try
>
> #1:
> F84: Event \BaseNamedObjects\pgident: postgres: bigbird
> bigbird 127.0.0.1(2367) SELECT
> EFC: File G:\pgsql\data\pg_xlog\000000010000010A0000006E
>
> #2:
> F84: Event \BaseNamedObjects\pgident: postgres: bigbird
> bigbird 127.0.0.1(2420) SELECT
> FF4: File G:\pgsql\data\pg_xlog\000000010000010A0000006E
>
> Nothing has the target file open.
>
> Pete
>
> >>> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 04/18/06 2:58 am >>>
> Yes, comment I added to dirmod.c give a hint:
>
> /*
> * We need these loops because even though PostgreSQL
> uses flags that
> * allow rename while the file is open, other
> applications might have
> * these files open without those flags.
> */
>
> so someone else has the file opened, but didn't use the
> required flags.
>
> As to what could have it open, I don't know.
>
>

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2006-04-18 14:50:58 Re: [Win32] Problem with rename()
Previous Message Harald Armin Massa 2006-04-18 14:35:19 Re: [Win32] Problem with rename()