> > 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.
>
> Hmm,don't you allow DDL commands inside transaction block ?
>
> 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
3. log rename successful or abort txn
> the old table file of t must vanish(using unlink() etc)
> before 'create table t'
> unless new file name is different from old one(OID file name would
> resolve the conflict in this case).
I was basing my statement on OID filenames being a factum.
I am only arguing against the extra version in the filename.
> To unlink/rename the table file immediately isn't a problem for the
> rollforward functionality. It seems a problem of rollback
> functionality.
only unlink cannot be done immediately a rename can be undone
and thus be executed immediately.
>
> > If a rename or delete fails we
> > bail out, since we don't want postmaster running under such
> circumstances
> > anyway.
>
> 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.
Andreas