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

Mon, 24 Jul 2000 12:29:02 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: 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 

Tue, 25 Jul 2000 08:55:32 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Vacuum only with 20% old tuples 