Re: Block B-Tree concept

Heikki Linnakangas wrote:
> Tom Lane wrote:
>> Anything that involves having VACUUM re-evaluate index expressions is a
>> nonstarter ... or have you already forgotten the optimizations we put
>> into 8.2 that assume, eg, no sub-transactions within a VACUUM?
>
> Umm, I'm afraid I have. Could you give me a clue?
I think I found it. Is this what you're talking about (in 
commands/vacuum.c):
       /*        * During a lazy VACUUM we do not run any user-supplied functions,        * and so it should be safe to
notcreate a transaction snapshot.        *        * We can furthermore set the inVacuum flag, which lets other        *
concurrentVACUUMs know that they can ignore this one while        * determining their OldestXmin.  (The reason we don't
setinVacuum        * during a full VACUUM is exactly that we may have to run user-        * defined functions for
functionalindexes, and we want to make        * sure that if they use the snapshot set above, any tuples it        *
requirescan't get removed from other tables.  An index function        * that depends on the contents of other tables
isarguably broken,        * but we won't break it here by violating transaction semantics.)        *        * Note: the
inVacuumflag remains set until CommitTransaction or        * AbortTransaction.  We don't want to clear it until we
reset       * MyProc->xid/xmin, else OldestXmin might appear to go backwards,        * which is probably Not Good.
 */       MyProc->inVacuum = true;
 

-- 
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com