
> One reason to do truncate is that if it is a symbolic link to another
> driver, that link will stay, while unlink will not, and will recreate on
> on the same drive.
> 
That is the first good argument in favor of truncate other than 
coding issues. I like it. It is actually very good :-)

My only concern with leaving the files around would be, that there is
a chance for other backends to write where they should not.

Andreas

Mon, 7 Jun 1999 16:56:09 +0200 
ZEUGSWETTER Andreas IZ5 <Andreas.Zeugswetter@telecom.at>
Re: [HACKERS] Open 6.5 items
ZEUGSWETTER Andreas IZ5 wrote:
> 
> > One reason to do truncate is that if it is a symbolic link to another
> > driver, that link will stay, while unlink will not, and will recreate on
> > on the same drive.
> >
> That is the first good argument in favor of truncate other than
> coding issues. I like it. It is actually very good :-)
> 
> My only concern with leaving the files around would be, that there is
> a chance for other backends to write where they should not.

Seems that shouldn't be problem here:

- only vacuum trancates relations;
- vacuum locks a relation in Access Exclusive mode;
- hepa_beginscan (used by both SeqScan and IndexScan)
  tries to lock a relation in Access Share mode _before_ 
  call to RelationGetNumberOfBlocks()->smgrnblocks();
- INSERT acquires Row Exclusive lock on relation
  before doing anything;

- so, anyone should get valid number of blocks.

But mdmgr should be tested...

Vadim

Mon, 07 Jun 1999 23:40:14 +0800
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] Open 6.5 items