> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > When VACUUM for a table starts, the transaction is not
> > committed yet of cource. After *commit* VACUUM has handled
> > heap/index tuples very carefully to be crash-safe before
> > 7.1. Currently another vacuum could be invoked in the
> > already committed transaction. There has been no such
> > situation before 7.1. Yes,VACUUM isn't crash-safe now.
>
> Vadim, do you agree with this argument? If so, I think it's
> something we need to fix. I don't see what Hiroshi is worried
> about, myself, but if there really is an issue here...
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).
I don't know how bad is it for TOAST tables though.
Vadim
P.S. I had no Inet access on weekends - my home phone line was broken...
