On Tue, Apr 19, 2011 at 4:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Namely, that when reindexing an
> existing index, there cannot be any need to advance the index's
> indcheckxmin horizon.
Note that if isvalid is not set then we don't know anything about the
hot chains since the concurrent index build never finished.
I'm also a bit concerned since the part of the use case of REINDEX is
for handling precisely the situations where the index is corrupt. If I
change the code for my user-defined data type and knowingly break the
semantics of the btree op, I might reasonably expect a REINDEX to fix
it up. ((I don't recall if we went with binary equality or btree
equality for determining of updates are eligible for hot updates or
not though.)
--
greg