From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | ZEUGSWETTER Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Open 6.5 items |
Date: | 1999-06-07 15:40:14 |
Message-ID: | 375BE7DE.436F44FD@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 1999-06-07 15:47:48 | Re: [HACKERS] Bug in LIKE ? |
Previous Message | Bruce Momjian | 1999-06-07 15:35:35 | Re: [COMMITTERS] 'pgsql/src/backend/parser gram.y' |