RE: [HACKERS] Current TODO list

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Ole Gjerde" <gjerde(at)icebox(dot)org>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [HACKERS] Current TODO list
Date: 1999-05-24 00:23:23
Message-ID: 000e01bea57b$a242cd80$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Ole Gjerde [mailto:gjerde(at)icebox(dot)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(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-24 00:43:33 Re: [HACKERS] strange behavior of UPDATE
Previous Message Andy Lewis 1999-05-24 00:21:08 Full Text Searches