Re: [HACKERS] 6.5 TODO list

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] 6.5 TODO list
Дата
Msg-id 21630.926466268@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] 6.5 TODO list  (gjerde@icebox.org)
Ответы Re: [HACKERS] 6.5 TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
gjerde@icebox.org writes:
> I have been looking at the code for dropping the table.  The code in
> mdunlink() seems to be correct, and *should* work.  Of course it don't, so
> I'll do some more testing tonight and hopefully I can figure out why it
> doesn't work.

Actually it looks a little peculiar to me.  The FileUnlink() routine in
fd.c is defined to delete (unlink) the physical file after closing the
virtual file descriptor for it.  If a VFD is being held for each segment
of the table then the calls to FileNameUnlink ought to be unnecessary,
not to mention possible causes of trouble on NFS disks since there might
still be open file descriptors for the files.

> I just got to thinking, what about indexes > 2GB?  With my 3GB table one
> of the index is 540MB.  Both with growth I might get there.  Does that
> work and does it use RELSEG_SIZE?

index_destroy in backend/catalog/index.c looks to be coping with only
one segment file ... not sure why it doesn't go through md.c for this.

Good luck tracking it all down...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Re: [SQL] plpgsql error
Следующее
От: Chris Bitmead
Дата:
Сообщение: Re: [HACKERS] Date/Time Flaw in pg_dump ?