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