Re: [HACKERS] v6.5 release ToDo

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