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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
