Re: What's left?

pgman wrote:
> > > PeerDirect handles rename by just looping. We really can't delay a
> > > rename. There is discussion in the Win32 TODO detail that goes over
> > > some options, I think.
> >
> > Do we really have any problem with rename? We don't rename table files.
> > The renames I can think of are renaming temp files into place as
> > permanent ones, and there would be no open references to such a file.
>
> We do have a problem. It is with cache files read on startup, like
> pg_pwd. We can generate the file as temp, but we have to slide it in
> while a backend is not reading it. On a busy system, I am not sure how
> large a window we will get for the rename. The rename is all
> centralized in port/dirmod.c, so we can deal with it there, whatever the
> solution.
>
> We also have to do the rename during xact close because we need to hold
> locks so we are sure the files are written in the same order that they
> modify pg_shadow, waiting a long time for the rename is a serious
> problem.

I think I have a solution to this. The problem with rename is that if
the file is open under win32, we can't rename, so we loop, but we are
still holding locks.

My idea is to do this:

grab lock(e.g. pg_shadow)
write temp file
rename temp file to realfile.new
release lock
rename realfile.new to realfile

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.

It's so easy, I think I could code it myself. :-)

This, along with the idea of having the checkpoint delete files that are
pending should solve both problems for us.

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