Assert failure when rechecking an exclusion constraint

Commit d2f60a3ab055fb61c8e1056a7c5652f1dec85e00 added an assert to indexam.c's
RELATION_CHECKS to block use of an index while it's being rebuilt.  This
assert trips while rechecking an exclusion constraint after an ALTER TABLE
rebuild:

	CREATE TABLE t (
		c	int,
		EXCLUDE (c WITH =)
	);

	INSERT INTO t VALUES (1), (2);
	ALTER TABLE t ALTER c TYPE smallint USING 1;

Here's the end of the stack trace (at -O1):

#0  0x00007f3d2bae3095 in raise () from /lib/libc.so.6
#1  0x00007f3d2bae4af0 in abort () from /lib/libc.so.6
#2  0x0000000000705449 in ExceptionalCondition (conditionName=<value optimized out>, errorType=<value optimized out>, fileName=<value optimized out>, lineNumber=<value optimized out>) at assert.c:57
#3  0x0000000000486148 in index_beginscan_internal (indexRelation=0x7f3d2c6990a0, nkeys=1, norderbys=0) at indexam.c:283
#4  0x000000000048622c in index_beginscan (heapRelation=0x7f3d2c68fb48, indexRelation=0x6a73, snapshot=0x7fff679d17b0, nkeys=-1, norderbys=0) at indexam.c:237
#5  0x000000000058a375 in check_exclusion_constraint (heap=0x7f3d2c68fb48, index=0x7f3d2c6990a0, indexInfo=0xc97968, tupleid=0xc8c06c, values=0x7fff679d18d0, isnull=0x7fff679d19e0 "", estate=0xc98ac8, newIndex=1 '\001', errorOK=0 '\000') at execUtils.c:1222
#6  0x00000000004d164e in IndexCheckExclusion (heapRelation=0x7f3d2c68fb48, indexRelation=0x7f3d2c6990a0, indexInfo=0xc97968, isprimary=0 '\000', isreindex=1 '\001') at index.c:2328
#7  index_build (heapRelation=0x7f3d2c68fb48, indexRelation=0x7f3d2c6990a0, indexInfo=0xc97968, isprimary=0 '\000', isreindex=1 '\001') at index.c:1765
#8  0x00000000004d21b8 in reindex_index (indexId=131529, skip_constraint_checks=0 '\000') at index.c:2814
#9  0x00000000004d2450 in reindex_relation (relid=<value optimized out>, flags=6) at index.c:2988
#10 0x000000000052a86a in finish_heap_swap (OIDOldHeap=131524, OIDNewHeap=131531, is_system_catalog=0 '\000', swap_toast_by_content=<value optimized out>, check_constraints=1 '\001', frozenXid=<value optimized out>) at cluster.c:1427
#11 0x000000000055fc1b in ATRewriteTables (rel=<value optimized out>, cmds=<value optimized out>, recurse=<value optimized out>, lockmode=8) at tablecmds.c:3329
#12 ATController (rel=<value optimized out>, cmds=<value optimized out>, recurse=<value optimized out>, lockmode=8) at tablecmds.c:2738
...

I could not come up with an actual wrong behavior arising from this usage, so
I'll tentatively call it a false positive.  reindex_index() could instead
unconditionally clear indexInfo->ii_Exclusion* before calling index_build(),
then pop pendingReindexedIndexes and call IndexCheckExclusion() itself.  Popping
pendingReindexedIndexes as we go can make the success of a reindex_relation()
dependent on the order in which we choose to rebuild indexes, though.

Another option is to just remove the assert as not worth preserving.

Opinions, other ideas?

Thanks,
nm