Greg Stark <stark@enterprisedb.com> writes:
> On Thu, Mar 26, 2009 at 7:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I realized what was bothering me about that patch: it could reset
>> indcheckxmin too soon, ie, while there are still transactions that
>> shouldn't use the index.
> That doesn't sound like the right solution. What we want to do is use
> the indcheckxmin for the newly built index if any -- ignoring any
> indcheckxmin from the previous index. The old value is completely
> irrelevant.
> What you describe would be right for the ALTER INDEX commands like
> RENAME or SET/RESET which might update the xmin without rebuilding the
> index contents. Likewise for CLUSTER/SET WITHOUT CLUSTER.
Hmm. You're right, I was thinking about the case of a generic update on
the pg_index row, but this particular patch is focused on REINDEX which
has just rebuilt the index contents. So never mind that.
However, I'm still unconvinced that it's safe to clear indcheckxmin
unconditionally. Isn't it possible for such a REINDEX to encounter
HOT chains that are (still) broken? Consider a REINDEX launched
right after a CREATE INDEX CONCURRENTLY (possibly a failed one),
while there are still open transactions older than the C.I.C.
We could reorganize the function slightly so that the IndexInfo is
still available after the PG_TRY block, and then do something like
"if (!indexInfo->ii_BrokenHotChain) reset indcheckxmin". This would
ensure that we didn't wipe the flag if index_build had just set it.
If I'm wrong and this can never happen, no harm done.
regards, tom lane
