From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block B-Tree concept |
Date: | 2006-09-27 05:50:57 |
Message-ID: | 20060927055057.GB19827@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-09-27 05:52:53 | Re: Block B-Tree concept |
Previous Message | Jim Nasby | 2006-09-27 05:34:06 | Re: Restart after power outage: createdb |