RE: [HACKERS] Current TODO list

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Current TODO list
Дата
Msg-id 000001bea31f$1f190680$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответ на RE: [HACKERS] Current TODO list  (The Hermit Hacker <scrappy@hub.org>)
Ответы Re: [HACKERS] Current TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Makefile Patch
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] Broken select on regular expression !!!