| 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: | Whole Thread | Raw Message | 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
| 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 |