On 9/14/07, Tom Lane <tgl@sss.pgh.pa.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