I believe also we have:
DROP TABLE/RENAME TABLE doesn't remove extended files, *.1, *.2
as an open item. Do you see these problems there?
> > > Prob #1:
> > > DROP TABLE <table> doesn't removed "extended" files.
> > > i.e., if you have 2GB db on Linux(i386), it will only delete the main
> > > file and not the .1, .2, etc table files.
>
> I have looked at this.
> I made it so it rolled over files at 1MB. My table ended up with 120
> segments, and my indexes had 3(Yes, it DOES work!).
> DROP TABLE removed ALL segments from the table, but only the main index
> segment.
>
> So it looks like removing the table itself is using mdunlink in md.c,
> while removing indexes uses FileNameUnlink() which only unlinks 1 file.
> As far as I can tell, calling FileNameUnlink() and mdunlink() is basically
> the same, except mdunlink() deletes any extra segments.
>
> I've done some testing and it seems to work. It also passes regression
> tests(except float8, geometry and rules, but that's normal).
>
> If this patch is right, this fixes all known multi-segment problems on
> Linux.
>
> Ole Gjerde
>
> Patch for index drop:
> --- src/backend/catalog/index.c 1999/05/10 00:44:55 1.71
> +++ src/backend/catalog/index.c 1999/05/15 06:42:27
> @@ -1187,7 +1187,7 @@
> */
> ReleaseRelationBuffers(userindexRelation);
>
> - if (FileNameUnlink(relpath(userindexRelation->rd_rel->relname.data)) < 0)
> + if (mdunlink(userindexRelation) != SM_SUCCESS)
> elog(ERROR, "amdestroyr: unlink: %m");
>
> index_close(userindexRelation);
>
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026