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

Mon, 11 Dec 2000 09:19:34 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Is VACUUM still crash-safe?
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> 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?

> I don't know how bad is it for TOAST tables though.

I still don't see anything here that affects the handling of TOAST
tables, which was Hiroshi's original complaint.

			regards, tom lane

Mon, 11 Dec 2000 12:36:55 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Is VACUUM still crash-safe? 