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