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
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;
