On Wed, Apr 20, 2011 at 3:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm, good point. We can probably handle this by tweaking the logic in
> reindex_index that changes indisvalid so that it will force indcheckxmin
> on when indisvalid had been false and there were any possibly-broken
> HOT chains.
I'm not following. You mean set indcheckxmin on the first phase when
we create the row with indisvalid false? Then when we set indisvalid
to true also clear indcheckxmin (or just leave it since we would have
waited out that xmin anyways)?
Seems like a reasonable thing to do just to make the invariant on
indcheckxmin simpler. But equally you could just make the check for
the optimization just check indisvalid && xmin > indcheckxmin. It's
always safe to bump indcheckxmin except for the pg_index case at hand,
just unnecessary sometimes.
I kind of wonder why you like this optimization better than the
bright-line "never update indcheckxmin on system table indexes" rule.
That seems to depend on a lot less subtle reasoning about system
tables not being built with create index concurrently etc. With the
simple rule we could have an elog() any time a broken hot chain is
detected in a system table when rebuilding an index and then it would
be easy enough to verify the correctness of the code by local
inspection instead of depending on understanding how the last index
built or rebuild might have set indcheckxmin on system indexes.
I like the optimization since it reduces the occurrency of the
indcheckxmin weirdness but I dislike counting on it for correctness on
pg_index.
--
greg