"Mikheev, Vadim" wrote:
>
> > > If we move tuples in already committed state, a page with new
> > > tuple position goes to disk and backend crashes before page with
> > > old tuple position updated then we'll have two version of tuple
> > > after restart (new tuple with HEAP_MOVED_IN is valid and there is
> > > no HEAP_MOVED_OFF in old tuple version).
> >
> > That's not good. Perhaps VACUUM still needs to fsync the file before
> > its internal commit?
>
> Ops, sorry - this case is not relevant to 7.1: WAL guarantees that
> both pages will be updated on restart. Seems we are safe now.
>
First,already committed state isn't a normal state at least without WAL.
We must have access to db as less as possible in the state without WAL.
AFAIK there has been no proof that we are sufficently safe in the
state under WAL. Don't you have to prove it if you dare to do another
vacuum in the state ?
Second,isn't the following an example that VACUUM isn't crash-safe.
VACUUM of a toast table crashed immediately after the movementof a tuple(and before inserting corresponding index
tuples).Unfortunatelythe movement of a tuple is directly committed inalready committed state but corresponding index
tuplesaren'tinserted.
Regards.
Hiroshi Inoue