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
