Re: Block B-Tree concept

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)