[HACKERS] Re: Is VACUUM still crash-safe?

[Hiroshi Inoue]

Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> 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