Re: [HACKERS] 6.5 TODO list - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] 6.5 TODO list
Date
Msg-id 21630.926466268@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] 6.5 TODO list  (gjerde@icebox.org)
Responses Re: [HACKERS] 6.5 TODO list  (Bruce Momjian <maillist@candle.pha.pa.us>)
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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [SQL] plpgsql error
Next
From: Chris Bitmead
Date:
Subject: Re: [HACKERS] Date/Time Flaw in pg_dump ?