RE: [HACKERS] Current TODO list - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] Current TODO list
Date
Msg-id 000e01bea57b$a242cd80$2801007e@cadzone.tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Current TODO list  (Ole Gjerde <gjerde@icebox.org>)
Responses Re: [HACKERS] Current TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] DEFAULT fixed
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] strange behavior of UPDATE