Re: [HACKERS] 6.5 TODO list

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

Responses

Browse pgsql-hackers by date

  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