On Tue, Sep 26, 2006 at 05:27:56PM +0100, Heikki Linnakangas wrote:
> 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 not create a transaction snapshot.
> *
> * We can furthermore set the inVacuum flag, which lets other
> * concurrent VACUUMs know that they can ignore this one while
> * determining their OldestXmin. (The reason we don't set inVacuum
> * during a full VACUUM is exactly that we may have to run user-
> * defined functions for functional indexes, and we want to make
> * sure that if they use the snapshot set above, any tuples it
> * requires can't get removed from other tables. An index function
> * that depends on the contents of other tables is arguably broken,
> * but we won't break it here by violating transaction semantics.)
> *
> * Note: the inVacuum flag 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;
Do I understand that to mean that you can no longer lazy vacuum a
functional index?
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)