Re: Another HOT thought: why do we need indcreatexid at all?

On 9/14/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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