Assert failure when rechecking an exclusion constraint

From: Noah Misch <noah(at)leadboat(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Assert failure when rechecking an exclusion constraint
Date: 2011-06-03 22:27:08
Message-ID: 20110603222708.GA27476@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2011-06-03 22:58:50 Re: [COMMITTERS] pgsql: Disallow SELECT FOR UPDATE/SHARE on sequences.
Previous Message Jeff Davis 2011-06-03 22:24:28 Re: [HACKERS] Postmaster holding unlinked files for pg_largeobject table