From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | gjerde(at)icebox(dot)org |
Cc: | PostgreSQL-development <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] 6.5 TODO list |
Date: | 1999-05-11 23:44:28 |
Message-ID: | 21630.926466268@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
gjerde(at)icebox(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bitmead | 1999-05-11 23:53:21 | Re: [HACKERS] Date/Time Flaw in pg_dump ? |
Previous Message | Tom Lane | 1999-05-11 23:26:15 | Re: [HACKERS] Re: [SQL] plpgsql error |