Re: Assertion failure in get_appendrel_parampathinfo

Postgres 9.4beta2 and later crashes given the following query:

BEGIN;

CREATE TABLE k (
id int
);
CREATE UNIQUE INDEX k_idx ON k (id);

INSERT INTO k VALUES(1);

CREATE TABLE link (
source int,
target int
);
CREATE UNIQUE INDEX l_idx ON link (source, target);

CREATE TABLE b (
id int
);
CREATE UNIQUE INDEX b_idx ON b (id);

CREATE TABLE d () INHERITS (b);
CREATE UNIQUE INDEX d_idx ON d (id);

ANALYZE;

SELECT
1
FROM
k AS k1
WHERE
EXISTS (
(SELECT
True
FROM
k AS k2

INNER JOIN (
link

INNER JOIN

(SELECT id FROM b
UNION ALL SELECT id FROM d) AS v

ON (link.target = v.id)

) ON (k2.id = link.source
AND k1.id = link.source)
)
);

ROLLBACK;

Which generates the following query plan:

QUERY PLAN
──────────────────────────────────────────────────────────────────────────────────────────────────
Seq Scan on k k1 (cost=0.00..1.33 rows=1 width=0)
Filter: (SubPlan 1)
SubPlan 1
-> Nested Loop (cost=0.15..44.43 rows=264 width=0)
-> Seq Scan on k k2 (cost=0.00..1.01 rows=1 width=4)
Filter: (id = k1.id)
-> Nested Loop (cost=0.15..40.77 rows=264 width=4)
-> Append (cost=0.00..40.18 rows=3 width=4)
-> Seq Scan on b (cost=0.00..0.00 rows=1 width=4)
Filter: (id = id)
-> Index Only Scan using d_idx on d d_1 (cost=0.15..0.18 rows=1 width=4)
Index Cond: (id = id)
-> Seq Scan on d (cost=0.00..40.00 rows=1 width=4)
Filter: (id = id)
-> Index Only Scan using l_idx on link (cost=0.15..0.19 rows=1 width=8)
Index Cond: ((source = k1.id) AND (target = b.id))
Planning time: 0.411 ms
(17 rows)

Traceback:

#0 0x00007fc0e05cc2f7 in raise () from /lib64/libc.so.6
#1 0x00007fc0e05cd638 in abort () from /lib64/libc.so.6
#2 0x00000000008e9445 in ExceptionalCondition (conditionName=0xa75e10 "!(!bms_overlap(appendrel->relids, required_outer))", errorType=0xa75b5a "FailedAssertion", fileName=0xa75b50 "relnode.c", lineNumber=983) at assert.c:54
#3 0x0000000000720dda in get_appendrel_parampathinfo (appendrel=0x13f6340, required_outer=0x1400c90) at relnode.c:983
#4 0x0000000000718b55 in create_append_path (rel=0x13f6340, subpaths=0x1403ff0, required_outer=0x1400c90) at pathnode.c:897
#5 0x00000000006d309a in set_append_rel_pathlist (root=0x13ef630, rel=0x13f6340, rti=3, rte=0x13ecbd8) at allpaths.c:855
#6 0x00000000006d23e1 in set_rel_pathlist (root=0x13ef630, rel=0x13f6340, rti=3, rte=0x13ecbd8) at allpaths.c:320
#7 0x00000000006d21c2 in set_base_rel_pathlists (root=0x13ef630) at allpaths.c:222
#8 0x00000000006d202f in make_one_rel (root=0x13ef630, joinlist=0x13f5cf0) at allpaths.c:152
#9 0x00000000006f846f in query_planner (root=0x13ef630, tlist=0x0, qp_callback=0x6fc460 <standard_qp_callback>, qp_extra=0x7fffe32c28a0) at planmain.c:236
#10 0x00000000006fa484 in grouping_planner (root=0x13ef630, tuple_fraction=1) at planner.c:1288
#11 0x00000000006f91d1 in subquery_planner (glob=0x1380d00, parse=0x13ec4d8, parent_root=0x13825b8, hasRecursion=0 '\000', tuple_fraction=1, subroot=0x7fffe32c2aa8) at planner.c:573
#12 0x000000000070288f in make_subplan (root=0x13825b8, orig_subquery=0x137dcd8, subLinkType=EXISTS_SUBLINK, subLinkId=0, testexpr=0x0, isTopQual=1 '\001') at subselect.c:490
#13 0x0000000000704b77 in process_sublinks_mutator (node=0x13ec480, context=0x7fffe32c2ba0) at subselect.c:1862
#14 0x0000000000704ada in SS_process_sublinks (root=0x13825b8, expr=0x13ec480, isQual=1 '\001') at subselect.c:1835
#15 0x00000000006f941c in preprocess_expression (root=0x13825b8, expr=0x13ec480, kind=0) at planner.c:693
#16 0x00000000006f94fc in preprocess_qual_conditions (root=0x13825b8, jtnode=0x1382850) at planner.c:738
#17 0x00000000006f8dae in subquery_planner (glob=0x1380d00, parse=0x137d8a0, parent_root=0x0, hasRecursion=0 '\000', tuple_fraction=0, subroot=0x7fffe32c2d48) at planner.c:443
#18 0x00000000006f86f8 in standard_planner (parse=0x137d8a0, cursorOptions=0, boundParams=0x0) at planner.c:210
#19 0x00000000006f855c in planner (parse=0x137d8a0, cursorOptions=0, boundParams=0x0) at planner.c:139
#20 0x00000000007b04c7 in pg_plan_query (querytree=0x137d8a0, cursorOptions=0, boundParams=0x0) at postgres.c:750
#21 0x00000000007b057a in pg_plan_queries (querytrees=0x1382580, cursorOptions=0, boundParams=0x0) at postgres.c:809
#22 0x00000000007b0885 in exec_simple_query (query_string=0x1309788 "BEGIN;\n\nCREATE TABLE k (\n id int\n);\nCREATE UNIQUE INDEX k_idx ON k (id);\n\nINSERT INTO k VALUES(1);\n\nCREATE TABLE link (\n source int,\n target int\n);\nCREATE UNIQUE INDEX l_idx ON link (source, "...) at postgres.c:974
#23 0x00000000007b4de6 in PostgresMain (argc=10, argv=0x12b5040, dbname=0x12d2350 "template1", username=0x12bcc60 "elvis") at postgres.c:4010
#24 0x000000000069757e in main (argc=10, argv=0x12b5040) at main.c:215

Elvis

Elvis Pranskevichus <elprans(at)gmail(dot)com> writes:
> Postgres 9.4beta2 and later crashes given the following query:

Thanks for the test case. Reproduces for me in HEAD, will look
into it later.

> Which generates the following query plan:

I'm a bit confused about your statement that it produces this query plan,
since AFAICS it crashes before getting that far.

regards, tom lane

Yeah, it crashes on debug build with asserts enabled when
planning.

In fact, it's possible to reproduce on a smaller query:

EXPLAIN SELECT
True
FROM
link
INNER JOIN (SELECT id FROM b
UNION ALL SELECT id FROM d) AS v
ON (link.target = v.id);

On non-debug build EXPLAIN works, but running it crashes in
ExecEvalScalarVar:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000596dd5 in ExecEvalScalarVar ()
(gdb) bt
#0 0x0000000000596dd5 in ExecEvalScalarVar ()
#1 0x00000000005a4f98 in ExecIndexEvalRuntimeKeys ()
#2 0x00000000005a66e8 in ExecReScanIndexOnlyScan ()
#3 0x000000000059057d in ExecReScan ()
#4 0x00000000005a66a5 in ExecIndexOnlyScan ()
#5 0x0000000000594498 in ExecProcNode ()
#6 0x000000000059f57f in ExecAppend ()
#7 0x00000000005944e8 in ExecProcNode ()
#8 0x00000000005aab87 in ExecNestLoop ()
#9 0x0000000000594408 in ExecProcNode ()
#10 0x0000000000591aa0 in standard_ExecutorRun ()
#11 0x0000000000678aa8 in PortalRunSelect ()
#12 0x0000000000679e2f in PortalRun ()
#13 0x0000000000677bc3 in PostgresMain ()
#14 0x000000000046adef in main ()

Elvis

On September 17, 2014 02:50:34 PM Tom Lane wrote:
> Elvis Pranskevichus <elprans(at)gmail(dot)com> writes:
> > Postgres 9.4beta2 and later crashes given the following
query:
> Thanks for the test case. Reproduces for me in HEAD, will
> look into it later.
>
> > Which generates the following query plan:
> I'm a bit confused about your statement that it produces this
> query plan, since AFAICS it crashes before getting that far.
>
> regards, tom lane