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

Vadim

Mon, 11 Dec 2000 10:00:54 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
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

Tue, 12 Dec 2000 08:59:07 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Is VACUUM still crash-safe?
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>  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.

Ah, *now* I see what you're talking about.  You're right, the TOAST
table has to be vacuumed under a separate transaction number.

I still don't like releasing the lock on the master table though.
VACUUM cheats on the commit already, could it start a new transaction
number without releasing the lock?

			regards, tom lane

Mon, 11 Dec 2000 20:46:46 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Is VACUUM still crash-safe? 
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> >  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.
> 
> Ah, *now* I see what you're talking about.  You're right, the TOAST
> table has to be vacuumed under a separate transaction number.
> 
> I still don't like releasing the lock on the master table though.
> VACUUM cheats on the commit already, could it start a new transaction
> number without releasing the lock?
> 

It is also preferable that we could replace current intermediate
*commit*
of vacuum by real commit(without releaseing the lock).
IIRC,Vadim and I talked about it a little once before.

We could avoid releasing the lock at commit time but probably
the next StartTransaction() has to change xid-s of LockTable
entries. I'm not sure if it's sufficient or not. For example
We could hardly keep row-level lock. We could acquire the lock
on a row which is already committed.

Regards.
Hiroshi Inoue

Tue, 12 Dec 2000 13:13:57 +0900
Hiroshi Inoue <Inoue@tpf.co.jp>
Re: Is VACUUM still crash-safe?