RE: [HACKERS] Current TODO list
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Current TODO list |
Дата | |
Msg-id | 000e01bea57b$a242cd80$2801007e@cadzone.tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Current TODO list (Ole Gjerde <gjerde@icebox.org>) |
Ответы |
Re: [HACKERS] Current TODO list
|
Список | pgsql-hackers |
> -----Original Message----- > From: Ole Gjerde [mailto:gjerde@icebox.org] > Sent: Saturday, May 22, 1999 1:37 AM > To: Bruce Momjian > Cc: Hiroshi Inoue; PostgreSQL-development > Subject: Re: [HACKERS] Current TODO list > > > On Thu, 20 May 1999, Bruce Momjian wrote: [snip] > > > > But my anxiety is the use of unlink()(FileNameUnlink()). > > > Unlink() is very dangerous. > > > Unlink() never remove the target file immediately.and even the > > > truncating process doesn't close the files by the patch and so > > > unlinked files are still alive for all processes which have already > > > opened the files. > > I don't think unlink() is a problem. That other backends have the files > open shouldn't matter. Whenever they close it(should be pretty quick), When are those files closed ? AFAIC,they are kept open until the backends which reference those files finish. Certainly,those files are re-opened(without closing) by backends after vacuum,though I don't know it's intentional or caused by side-effect. But unfortunately,re-open is not sufficiently quick. And I think that the assumption of mdtruncate() is not clear. Could we suppose that unlinked files are closed quickly for all backends by the caller of mdunlink() ? Thanks. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: