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