[sqlsmith] Failed assertion on pfree() via perform_pruning_combine_step
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
Attachments:
prune-combine-intersect-bugfix.patchtext/plain; charset=UTF-8; name=prune-combine-intersect-bugfix.patchDownload
diff --git a/src/backend/partitioning/partprune.c b/src/backend/partitioning/partprune.c
index 417e1fee81..0f0080928a 100644
--- a/src/backend/partitioning/partprune.c
+++ b/src/backend/partitioning/partprune.c
@@ -2923,7 +2923,8 @@ perform_pruning_combine_step(PartitionPruneContext *context,
if (firststep)
{
/* Copy step's result the first time. */
- result->bound_offsets = step_result->bound_offsets;
+ result->bound_offsets =
+ bms_copy(step_result->bound_offsets);
result->scan_null = step_result->scan_null;
result->scan_default = step_result->scan_default;
firststep = false;
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.
/messages/by-id/E1f5XK3-0004Em-QZ@gemulon.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