It is good that moving the file out of the way works, but it doesn't
completely solve the problem.
What we have now with Unix rename is ideal:
1) old opens continue seeing the old contents
2) new opens see the new contents
3) the file always exists under the fixed name
We have that with MoveFileEx(), but we have to loop over the routine
until is succeeds. If we move the old file out of the way, we loose the
ability to know the file always exists and then we have to loop over
open() until is succeeds.
I think we may be best just looping on MoveFileEx() until is succeeds.
We do the pg_pwd writes while holding an exclusive lock on pg_shadow so
that will guarantee that no one else will slip an old version of the
file in after we have written it. However, it also prevents pg_shadow
access while we are doing the looping. Yuck.
---------------------------------------------------------------------------
Mike Mascari wrote:
> Stephan Szabo wrote:
> > On Fri, 20 Sep 2002, Mike Mascari wrote:
> >>Bruce Momjian wrote:
> >>>Mike Mascari wrote:
> >>>>Actually, looking at the pg_pwd code, you want to determine a
> >>>>way for:
> >>>>
> >>>>1. Process 1 opens "foo"
> >>>>2. Process 2 opens "foo"
> >>>>3. Process 1 creates "bar"
> >>>>4. Process 1 renames "bar" to "foo"
> >>>>5. Process 2 can continue to read data from the open file handle
> >>>>and get the original "foo" data.
> >>>
> >>>
> >>>Yep, that's it.
> >>>
> >>
> >>So far, MoveFileEx("foo", "bar", MOVEFILE_REPLACE_EXISTING)
> >>returns "Access Denied" when Process 1 attempts the rename. But
> >>I'm continuing to investigate the possibilities...
> >
> >
> > Does a sequence like
> > Process 1 opens "foo"
> > Process 2 opens "foo"
> > Process 1 creates "bar"
> > Process 1 renames "foo" to <something>
> > - where something is generated to not overlap an existing file
> > Process 1 renames "bar" to "foo"
> > Process 2 continues reading
> > let you do the replace and keep reading (at the penalty that
> > you've now got to have a way to know when to remove the
> > various <something>s)
>
> Yes! Indeed that does work.
>
> Mike Mascari
> [EMAIL PROTECTED]
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
