Re: Is VACUUM still crash-safe?

"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 movement
of a tuple(and before inserting corresponding index tuples).
Unfortunately the movement of a tuple is directly committed in
already committed state but corresponding index tuples aren't
inserted.

Regards.
Hiroshi Inoue