Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think it will very likely rename/unlink will fail because of the file
> descriptor cache kept by each backend.
Hmm ... you're probably right. Okay, it's a more significant issue than
I thought.
> I am attaching dir.c from the PeerDirect port. It handles unlink
> failures by appending the failed file name to a file that is later read
> and another unlink attempted. Perhaps this is something we can do, and
> have try unlinks after each checkpoint.
That seems like a possibility. The open files will get closed very soon
after the delete occurs (as a byproduct of relcache flush), so we don't
need very much of a delay. Next checkpoint sounds reasonable.
> 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.
regards, tom lane