Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > In this way, no one ever has the rename file open while we are holding
> > > the locks, and we can loop without holding an exclusive lock on
> > > pg_shadow, and file writes remain in order.
> >
> > You're doing this where exactly, and are certain that you are holding no
> > locks why exactly? And if you aren't holding a lock, what prevents
> > concurrency bugs?
>
> Oh, for concurrency bugs, you make realfile.new while holding the
> exclusive lock, so someone could come in later and replace realfile.new
> while I am in the rename loop, but then I just install theirs instead.
>
> I could install someone who has just done the rename to realfile.new but
> not tried the rename from realfile.new to realfile, but that seems OK.
> They will just fine the file missing and fail on the rename, which is
> OK.
OK, here is a patch that I think handles rename. It does the rename to
a secondary file while holding the lock, then releases the lock and does
a rename to the active file. I enabled this for Win32 and Cygwin, which
has the same file system behavior.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073