RE: Vacuum only with 20% old tuples

> -----Original Message-----
> From: Zeugswetter Andreas SB
> 
> > > WAL can solve the versioned relations problem.
> > > Remember that a sure new step in postmaster startup will be a
> > > rollforward of the WAL,
> > > since that will have the only sync write of our last txn's. 
> > > Thus in this step it can also
> > > do any pending rename or delete of files.
> > 
> > If we allow DDL commands inside transaction block,WAL couldn't
> > postpone all rename/unlink operations until the end of transaction
> > without a resolution of the conflict of table file name.
> 
> It does not postpone anything. WAL only logs what it does:
> 
> 1. log i now start to rename file
> 2. rename file

How do we log *rename* ?
What I've meant by *rename* is to replace an existent table
file by a (e.g. work temp) file.  So the old table file would
vanish by renaming. How to save the content for rollback ?
Is it preferable to save the content entirely to WAL log file ?
If *rename* is possible,are OID filenames necessary in the
first place ? 

> 3. log rename successful or abort txn
>
> > 
> > No there's a significant difference between the failure of  'delete'
> > and that of 'rename'.  We would have no consistency problem even
> > though 'delete' fails and wouldn't have to stop postmaster. But we
> > wouldn't be able to see the renamed relation in case of 'rename'
> > failure and an excellent(??) dba would have to recover the 
> > inconsistency.
> 
> The dba only fixes the underlying problem, like filesystem 
> mounted readonly 
> or wrong permissions on directory. He then simply starts the postmaster
> again,
> the rollforward with rename will then succeed.
>

Mustn't a dba be there to restart the postmaster when *rename*
fails ? We don't need a dba even when *delete* fails after commit.

Hiroshi Inoue
Inoue@tpf.co.jp