Обсуждение: [sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step
[sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step
От
Andreas Seltenreich
Дата:
Hi,
testing with master at 039eb6e92f yielded another query triggering an
assertion. Backtrace and query against the regression database below.
regards,
Andreas
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f25474cf42a in __GI_abort () at abort.c:89
#2 0x0000556c14b75bb3 in ExceptionalCondition (
conditionName=conditionName@entry=0x556c14d11510 "!(((context) != ((void *)0) && (((((const
Node*)((context)))->type)== T_AllocSetContext) || ((((const Node*)((context)))->type) == T_SlabContext) || ((((const
Node*)((context)))->type)== T_Generatio"...,
errorType=errorType@entry=0x556c14bcac95 "BadArgument",
fileName=fileName@entry=0x556c14d11480 "../../../../src/include/utils/memutils.h",
lineNumber=lineNumber@entry=129)
at assert.c:54
#3 0x0000556c14ba28cb in GetMemoryChunkContext (pointer=<optimized out>) at
../../../../src/include/utils/memutils.h:129
#4 pfree (pointer=<optimized out>) at mcxt.c:1033
#5 0x0000556c1495fc01 in bms_int_members (a=<optimized out>, b=<optimized out>) at bitmapset.c:917
#6 0x0000556c149d910a in perform_pruning_combine_step (context=0x7ffe80889b20, step_results=0x7f253e3efcc0,
cstep=0x7f253e3f13a0)
at partprune.c:2697
#7 get_matching_partitions (context=0x7ffe80889b20, pruning_steps=<optimized out>) at partprune.c:317
#8 0x0000556c149d9596 in prune_append_rel_partitions (rel=rel@entry=0x7f253e3eb3e8) at partprune.c:262
#9 0x0000556c14989e21 in set_append_rel_size (rte=0x7f254819d810, rti=2, rel=0x7f253e3eb3e8, root=0x7f254819d3c8) at
allpaths.c:907
#10 set_rel_size (root=root@entry=0x7f254819d3c8, rel=rel@entry=0x7f253e3eb3e8, rti=rti@entry=2, rte=0x7f254819d810)
at allpaths.c:341
#11 0x0000556c1498afad in set_base_rel_sizes (root=<optimized out>) at allpaths.c:281
#12 make_one_rel (root=root@entry=0x7f254819d3c8, joinlist=joinlist@entry=0x7f253e3f0100) at allpaths.c:179
#13 0x0000556c149abfac in query_planner (root=root@entry=0x7f254819d3c8, tlist=tlist@entry=0x7f25481afdc0,
qp_callback=qp_callback@entry=0x556c149acb90 <standard_qp_callback>, qp_extra=qp_extra@entry=0x7ffe80889dc0) at
planmain.c:259
#14 0x0000556c149b0be5 in grouping_planner (root=root@entry=0x7f254819d3c8,
inheritance_update=inheritance_update@entry=false,
tuple_fraction=<optimized out>, tuple_fraction@entry=0) at planner.c:1914
#15 0x0000556c149b31a1 in subquery_planner (glob=<optimized out>, parse=parse@entry=0x556c16bf4c88,
parent_root=parent_root@entry=0x556c16bf6360, hasRecursion=hasRecursion@entry=false, tuple_fraction=<optimized
out>)
at planner.c:984
#16 0x0000556c149899d3 in set_subquery_pathlist (rte=<optimized out>, rti=<optimized out>, rel=0x556c16c0f6a0,
root=0x556c16bf6360)
at allpaths.c:2196
#17 set_rel_size (root=root@entry=0x556c16bf6360, rel=rel@entry=0x556c16c0eaf0, rti=rti@entry=2, rte=<optimized out>)
at allpaths.c:379
#18 0x0000556c1498afad in set_base_rel_sizes (root=<optimized out>) at allpaths.c:281
#19 make_one_rel (root=root@entry=0x556c16bf6360, joinlist=joinlist@entry=0x556c16c0eda8) at allpaths.c:179
#20 0x0000556c149abfac in query_planner (root=root@entry=0x556c16bf6360, tlist=tlist@entry=0x556c16c0d928,
qp_callback=qp_callback@entry=0x556c149acb90 <standard_qp_callback>, qp_extra=qp_extra@entry=0x7ffe8088a200) at
planmain.c:259
#21 0x0000556c149b0be5 in grouping_planner (root=root@entry=0x556c16bf6360,
inheritance_update=inheritance_update@entry=false,
tuple_fraction=<optimized out>, tuple_fraction@entry=0) at planner.c:1914
#22 0x0000556c149b31a1 in subquery_planner (glob=glob@entry=0x556c16bf5bf0, parse=parse@entry=0x556c16bf4da0,
parent_root=parent_root@entry=0x0, hasRecursion=hasRecursion@entry=false, tuple_fraction=tuple_fraction@entry=0)
at planner.c:984
#23 0x0000556c149b4356 in standard_planner (parse=0x556c16bf4da0, cursorOptions=256, boundParams=<optimized out>) at
planner.c:405
#24 0x0000556c14a680dd in pg_plan_query (querytree=0x556c16bf4da0, cursorOptions=256, boundParams=0x0) at
postgres.c:808
#25 0x0000556c14a681be in pg_plan_queries (querytrees=<optimized out>, cursorOptions=cursorOptions@entry=256,
boundParams=boundParams@entry=0x0) at postgres.c:874
#26 0x0000556c14a686a9 in exec_simple_query ( query_string=0x556c16b2b438 "...") at postgres.c:1049
#27 0x0000556c14a6a341 in PostgresMain (argc=<optimized out>, argv=argv@entry=0x556c16b56ad8, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4149
#28 0x0000556c1474eac4 in BackendRun (port=0x556c16b4c030) at postmaster.c:4409
#29 BackendStartup (port=0x556c16b4c030) at postmaster.c:4081
#30 ServerLoop () at postmaster.c:1754
#31 0x0000556c149ec017 in PostmasterMain (argc=3, argv=0x556c16b257d0) at postmaster.c:1362
#32 0x0000556c1475006d in main (argc=3, argv=0x556c16b257d0) at main.c:228
select
sample_0.dd as c0,
subq_1.c3 as c1,
subq_1.c0 as c2,
subq_1.c2 as c3,
subq_1.c3 as c4,
sample_0.bb as c5,
subq_1.c0 as c6,
pg_catalog.pg_current_wal_flush_lsn() as c7,
public.func_with_bad_set() as c8,
sample_0.bb as c9,
sample_0.aa as c10,
sample_0.dd as c11
from
public.d as sample_0 tablesample bernoulli (2.8) ,
lateral (select
subq_0.c1 as c0,
sample_0.aa as c1,
subq_0.c0 as c2,
sample_0.cc as c3,
subq_0.c0 as c4,
subq_0.c1 as c5
from
(select
sample_1.a as c0,
(select s from public.reloptions_test limit 1 offset 2)
as c1
from
public.pagg_tab_ml as sample_1 tablesample system (3.6)
where ((((select c from public.test_tbl3 limit 1 offset 2)
<= cast(null as test_type3))
or (((select n from testxmlschema.test2 limit 1 offset 1)
<= true)
or (sample_0.bb is not NULL)))
and ((true)
or ((cast(null as varbit) >= (select varbitcol from public.brintest limit 1 offset 3)
)
and ((select macaddrcol from public.brintest limit 1 offset 6)
<> cast(null as macaddr)))))
or ((sample_1.a is NULL)
and ((sample_1.c is not NULL)
or (sample_1.c is NULL)))) as subq_0
where (select salary from public.rtest_emp limit 1 offset 3)
= (select pg_catalog.min(newsal) from public.rtest_emplog)
limit 13) as subq_1
where sample_0.aa is NULL
limit 140;
Hi Andreas. On 2018/04/08 3:33, Andreas Seltenreich wrote: > Hi, > > testing with master at 039eb6e92f yielded another query triggering an > assertion. Thanks for the report. > Backtrace and query against the regression database below. > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x00007f25474cf42a in __GI_abort () at abort.c:89 > #2 0x0000556c14b75bb3 in ExceptionalCondition ( > conditionName=conditionName@entry=0x556c14d11510 "!(((context) != ((void *)0) && (((((const Node*)((context)))->type)== T_AllocSetContext) || ((((const Node*)((context)))->type) == T_SlabContext) || ((((const Node*)((context)))->type)== T_Generatio"..., > errorType=errorType@entry=0x556c14bcac95 "BadArgument", > fileName=fileName@entry=0x556c14d11480 "../../../../src/include/utils/memutils.h", lineNumber=lineNumber@entry=129) > at assert.c:54 > #3 0x0000556c14ba28cb in GetMemoryChunkContext (pointer=<optimized out>) at ../../../../src/include/utils/memutils.h:129 > #4 pfree (pointer=<optimized out>) at mcxt.c:1033 > #5 0x0000556c1495fc01 in bms_int_members (a=<optimized out>, b=<optimized out>) at bitmapset.c:917 > #6 0x0000556c149d910a in perform_pruning_combine_step (context=0x7ffe80889b20, step_results=0x7f253e3efcc0, cstep=0x7f253e3f13a0) > at partprune.c:2697 > #7 get_matching_partitions (context=0x7ffe80889b20, pruning_steps=<optimized out>) at partprune.c:317 > #8 0x0000556c149d9596 in prune_append_rel_partitions (rel=rel@entry=0x7f253e3eb3e8) at partprune.c:262 > #9 0x0000556c14989e21 in set_append_rel_size (rte=0x7f254819d810, rti=2, rel=0x7f253e3eb3e8, root=0x7f254819d3c8) at allpaths.c:907 [ <snipped> ] > select > sample_0.dd as c0, > subq_1.c3 as c1, > subq_1.c0 as c2, > subq_1.c2 as c3, > subq_1.c3 as c4, > sample_0.bb as c5, > subq_1.c0 as c6, > pg_catalog.pg_current_wal_flush_lsn() as c7, > public.func_with_bad_set() as c8, > sample_0.bb as c9, > sample_0.aa as c10, > sample_0.dd as c11 > from > public.d as sample_0 tablesample bernoulli (2.8) , > lateral (select > subq_0.c1 as c0, > sample_0.aa as c1, > subq_0.c0 as c2, > sample_0.cc as c3, > subq_0.c0 as c4, > subq_0.c1 as c5 > from > (select > sample_1.a as c0, > (select s from public.reloptions_test limit 1 offset 2) > as c1 > from > public.pagg_tab_ml as sample_1 tablesample system (3.6) > where ((((select c from public.test_tbl3 limit 1 offset 2) > <= cast(null as test_type3)) > or (((select n from testxmlschema.test2 limit 1 offset 1) > <= true) > or (sample_0.bb is not NULL))) > and ((true) > or ((cast(null as varbit) >= (select varbitcol from public.brintest limit 1 offset 3) > ) > and ((select macaddrcol from public.brintest limit 1 offset 6) > <> cast(null as macaddr))))) > or ((sample_1.a is NULL) > and ((sample_1.c is not NULL) > or (sample_1.c is NULL)))) as subq_0 > where (select salary from public.rtest_emp limit 1 offset 3) > = (select pg_catalog.min(newsal) from public.rtest_emplog) > > limit 13) as subq_1 > where sample_0.aa is NULL > limit 140; I have reproduced this and found that the problem is that perform_pruning_combine_step forgets to *copy* the bitmapset of the first step in the handling of an COMBINE_INTERSECT step. Attached fixes that. I see that Michael Paquier has added this to the open items list. Thanks, Michael. https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Open_Issues Thanks, Amit
Вложения
On 2018/04/09 17:50, Amit Langote wrote: > Attached fixes that. I see that Michael Paquier has added this to the > open items list. Thanks, Michael. > > https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Open_Issues Oops, it was Tom who added that. Thank you! Regards, Amit
Hello, Amit Langote wrote: > I have reproduced this and found that the problem is that > perform_pruning_combine_step forgets to *copy* the bitmapset of the first > step in the handling of an COMBINE_INTERSECT step. Pushed, thanks Amit and Andreas! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018/04/09 22:59, Alvaro Herrera wrote: > Hello, > > Amit Langote wrote: > >> I have reproduced this and found that the problem is that >> perform_pruning_combine_step forgets to *copy* the bitmapset of the first >> step in the handling of an COMBINE_INTERSECT step. > > Pushed, thanks Amit and Andreas! Thanks! Regards, Amit
On Mon, Apr 09, 2018 at 10:59:48AM -0300, Alvaro Herrera wrote: > Amit Langote wrote: >> I have reproduced this and found that the problem is that >> perform_pruning_combine_step forgets to *copy* the bitmapset of the first >> step in the handling of an COMBINE_INTERSECT step. > > Pushed, thanks Amit and Andreas! Álvaro, didn't you forget to actually push the patch? -- Michael
Вложения
On 2018/04/10 13:55, Michael Paquier wrote: > On Mon, Apr 09, 2018 at 10:59:48AM -0300, Alvaro Herrera wrote: >> Amit Langote wrote: >>> I have reproduced this and found that the problem is that >>> perform_pruning_combine_step forgets to *copy* the bitmapset of the first >>> step in the handling of an COMBINE_INTERSECT step. >> >> Pushed, thanks Amit and Andreas! > > Álvaro, didn't you forget to actually push the patch? I too thought the same yesterday, as I couldn't see the commit even after about 35 minutes Alvaro actually had sent the email to -hackers (quoted above). But I found that the commit moments after: * Add missed bms_copy() in perform_pruning_combine_step * https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7ba6ee815dc90d4fab7226d343bf72aa28c9aa5c The mail to pgsql-committers may also have been delayed, but I did see it yesterday. https://www.postgresql.org/message-id/E1f5XK3-0004Em-QZ%40gemulon.postgresql.org Thanks, Amit
On Tue, Apr 10, 2018 at 03:15:47PM +0900, Amit Langote wrote: > I too thought the same yesterday, as I couldn't see the commit even after > about 35 minutes Alvaro actually had sent the email to -hackers (quoted > above). Bah, of course. Sorry for the noise. -- Michael