> -----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
