RE: Vacuum only with 20% old tuples

> -----Original Message-----
> From: Zeugswetter Andreas SB [mailto:ZeugswetterA@wien.spardat.at]
> 
> > > 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
>

OK,I see. Your idea seems to be close to Vadim's *relink*. 
However it isn't clear if *relink* has no problem.
In my test case on cygwin port ,*relink* doesn't work well.
*relink* caused an error if concurrent backends open the
*relink*ing table. 
> >  
> > > > 
> > > > 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).
>

Yes,I don't want a dba to deal with such an unrelible recovery.
Probably vacuum must be wise enough to remove unremoved
table files before removing dead pg_class tuples.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp