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

From Hiroshi Inoue
Subject RE: [HACKERS] Current TODO list
Date
Msg-id 000001bea31f$1f190680$2801007e@cadzone.tpf.co.jp
Whole thread Raw
In response to RE: [HACKERS] Current TODO list  (The Hermit Hacker <scrappy@hub.org>)
Responses Re: [HACKERS] Current TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers

> -----Original Message-----
> From: The Hermit Hacker [mailto:scrappy@hub.org]
> Sent: Thursday, May 20, 1999 7:59 PM
> To: Hiroshi Inoue
> Cc: Tom Lane; Peter T Mount; Bruce Momjian; PostgreSQL-development
> Subject: RE: [HACKERS] Current TODO list
>
>
> On Wed, 19 May 1999, Hiroshi Inoue wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: owner-pgsql-hackers@postgreSQL.org
> > > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> > > Sent: Tuesday, May 18, 1999 11:41 PM
> > > To: Peter T Mount
> > > Cc: Bruce Momjian; PostgreSQL-development
> > > Subject: Re: [HACKERS] Current TODO list
> > >
> > >
> > > Peter T Mount <peter@retep.org.uk> writes:
> > > > This was done (twice if I remember). The tables now split
> at 1G. This
> > > > opened a new problem that vacuum can't handle segmented tables.
> > > I have the
> > > > general idea of how to fix this, but again it's time that's
> the problem.
> > >
> > > Ole Gjerde <gjerde@icebox.org> just contributed a patch for the vacuum
> > > problem.  Perhaps you at least have time to check his patch?
> > >
> >
> > I wonder that no one but me object to the patch.
> > It may cause serious results.
>
> How?  Why?  In what way?  Details?
>

I don't have tables > 1G.
So I won't be damaged by the patch.

But I don't understand what Beta is.
Why isn't such a dangerous fucntion checked and tested
carefully ?

For example,the following code is not changed by the patch.
       if (FileTruncate(v->mdfd_vfd, nblocks * BLCKSZ) < 0)               return -1;

It never truncate segmented files and there may be cases the
original file increases its size(ftruncate() increases the size of
target file if the requested size is longer than the actual size).
It's not checked and tested and once it occurs I don't know
what will happen.

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.
Who checked and tested the influence carefully ?

I think it's not so easy to implement and check mdtruncate().

Thanks.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Makefile Patch
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Broken select on regular expression !!!