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
|
Список | 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 по дате отправления: