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