> > You have to tell us whether you plan to implement 
> > a safe file rename in WAL ? If yes a simple filename
> > without version would be possible and better.
> 
> What do you mean?

The previous discussion we had where we concluded, that 
an os rename of a file cannot be done without risc.
But that risc was imho acceptable to avoid the extra version in the filename

(a rename back to the old name could fail when the tx is supposed 
to be rolled back).

Search the archive for "file rename sync".

My conlusion would be an oid only filename, or a mixture of
oid and tablename, where tablename can be wildcarded on a directory search,
since oid is already unique. No version in the name, we would do renames in
that case.

If I remember correctly a patch exists that does oid only filenames.

Andreas


> > 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
Thu, 14 Sep 2000 09:47:07 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Status of new relation file naming