Re: What's left?
| От | Tom Lane |
|---|---|
| Тема | Re: What's left? |
| Дата | |
| Msg-id | 1038.1075094784@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: What's left? (Bruce Momjian <pgman@candle.pha.pa.us>) |
| Ответы |
Re: What's left?
|
| Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: