From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | seg fault in contrib/bloom |
Date: | 2016-05-17 17:25:44 |
Message-ID: | CAMkU=1yQtRY1qnXs9KgZOjbx0qsb8D_MdsGQ-w+2-wt+BdPhGA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm getting seg faults on contrib/bloom when updating a tuple which
was found via a bloom index.
It does not happen on every update, but it does happen within a few
seconds of run time, so it is readily reproducible. The test harness
is a bit of a mess, I'll try to clean it up and post it if no one
spots the bug soon via looking at the stack trace below.
Obviously scan->opaque is null, but I don't know why it is null and
whether blendscan is obliged to deal with nulls, or if index_endscan
is obliged not to send them.
No crash/recovery cycles are necessary to reach this bug.
Program terminated with signal 11, Segmentation fault.
#0 blendscan (scan=0x248bf40) at blscan.c:79
79 if (so->sign)
(gdb) bt
#0 blendscan (scan=0x248bf40) at blscan.c:79
#1 0x00000000004a9115 in index_endscan (scan=0x248bf40) at indexam.c:339
#2 0x00000000005d5839 in ExecEndBitmapIndexScan (node=<value
optimized out>) at nodeBitmapIndexscan.c:183
#3 0x00000000005d4e57 in ExecEndBitmapHeapScan (node=0x24894d8) at
nodeBitmapHeapscan.c:508
#4 0x00000000005c1585 in EvalPlanQualEnd (epqstate=0x246d078) at
execMain.c:2889
#5 0x00000000005ddc17 in ExecEndModifyTable (node=0x246cfd0) at
nodeModifyTable.c:1972
#6 0x00000000005c2e9e in ExecEndPlan (queryDesc=<value optimized
out>) at execMain.c:1451
#7 standard_ExecutorEnd (queryDesc=<value optimized out>) at execMain.c:468
#8 0x00000000006daac0 in ProcessQuery (plan=0x2478e20,
sourceText=0x23e4770 "update foo set count=count+1 where bloom=$1",
params=0x23e47e0,
dest=<value optimized out>, completionTag=0x7ffed6dff960 "UPDATE
1") at pquery.c:230
#9 0x00000000006dac9f in PortalRunMulti (portal=0x23d43b0,
isTopLevel=1 '\001', dest=0xc05660, altdest=0xc05660,
completionTag=0x7ffed6dff960 "UPDATE 1")
at pquery.c:1267
#10 0x00000000006db32a in PortalRun (portal=0x23d43b0,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x2437c60,
altdest=0x2437c60,
completionTag=0x7ffed6dff960 "UPDATE 1") at pquery.c:813
#11 0x00000000006d9612 in exec_execute_message (argc=<value optimized
out>, argv=<value optimized out>, dbname=0x23df128 "jjanes",
username=<value optimized out>) at postgres.c:1979
#12 PostgresMain (argc=<value optimized out>, argv=<value optimized
out>, dbname=0x23df128 "jjanes", username=<value optimized out>) at
postgres.c:4122
#13 0x0000000000676a05 in BackendRun (argc=<value optimized out>,
argv=<value optimized out>) at postmaster.c:4258
#14 BackendStartup (argc=<value optimized out>, argv=<value optimized
out>) at postmaster.c:3932
#15 ServerLoop (argc=<value optimized out>, argv=<value optimized
out>) at postmaster.c:1690
#16 PostmasterMain (argc=<value optimized out>, argv=<value optimized
out>) at postmaster.c:1298
#17 0x00000000005ff9e8 in main (argc=4, argv=0x23b5d50) at main.c:228
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2016-05-17 17:44:05 | Jsonb array-style subscripting, generic version |
Previous Message | Tom Lane | 2016-05-17 17:22:42 | Re: Declarative partitioning |