AW: Vacuum only with 20% old tuples - Mailing list pgsql-hackers

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

No, step 2 was meant to do the actual rename.
You log before and after the actual 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. 

you need to rename the old file first then the new file

> How to save the content for rollback ?

with rename of old file

> Is it preferable to save the content entirely to WAL log file ?

no, unless you have log space to spare, but not enough data space,
which is imho unlikely (or to be considered later).

> If *rename* is possible,are OID filenames necessary in the
> first place ? 

no

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

The dba needs to clean up unused file space later, 
which leaves the problem for the dba to decide which file is needed 
and what not (quite difficult with an oid filename).

But, rename is only supposed to fail if something is wrong with the
filesystem or directory. There will be a lot of other problems,
like creating sort files etc if that is the case. 
If a rename fails under normal operation the current transaction is aborted,
but you are correct that there is a problem if previous renames in the same 
transaction succeeded, but all further renames (for rollback) fail (is this
likely ?).
In that unlikely case I would bail out, let the dba fix the problem and fix
the db
state at startup rollforward (which can now rename and thus abort the txn). 

Andreas