Greg Stark <gsstark@mit.edu> writes:
> 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)?
No, I'm talking about the code at the bottom of reindex_index() that
will set indisvalid true at the end of a regular not-concurrent REINDEX
operation. If we had REINDEX CONCURRENTLY, it might have to address
this issue in some other fashion, but we don't and I don't desire to
design how it would work right now.
> I kind of wonder why you like this optimization better than the
> bright-line "never update indcheckxmin on system table indexes" rule.
That's not a "bright line" so much as a hack. System indexes really
shouldn't be that much different from ordinary indexes. The property
we actually are relying on is that there can't be any HOT chains that
break the index, because it existed before any updates could have
happened. I think the new approach is a more direct implementation of
that concept than the original.
regards, tom lane