On 9/14/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > I would still desperately like to get rid of indcreatexid, though, > because the patch's existing mechanism for clearing it is junk. > There's no guarantee that it will get cleared before it wraps around, > because the clearing is attached to vacuuming of the wrong table. > Maybe you could make it work by special-casing vacuuming of pg_index > itself, but the whole thing's a crock anyway.
Hmm.. I kind of agree, though I thought the base table must receive a vacuum for wrap-around purpose (because it contained a RECENTLY_DEAD tuple) and we should be able to fix indcreatexid in that context. But if we do anything to get away from it, that will be great. [ thinks some more ... ] Hmm, maybe instead of an explicit XID stored in > the pg_index row proper, we could use the xmin of the pg_index row > itself? That's already got a working mechanism for getting frozen. > > I think this a great idea. I think we can use the relation->indextuple to get pg_index row's xmin. But we need to add appropriate relcache invalidation when we freeze a tuple (at least for pg_index tuples) and reload this information in relation->indextuple in RelationReloadIndexInfo() Am I on right track ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
