On Wed, Apr 20, 2011 at 3:02 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers