Small query using LATERAL that segfaults Postgres
This small query seems to segfault Postgres. I've tried on the
version of Postgres 11 that comes with Debian Stable and all versions
on https://www.db-fiddle.com/ including 13 (Beta). DB Fiddle actually
says "An unexpected error occurred." but I suspect that's the
segfault.
Tom
SELECT
0
FROM (SELECT
TRUE as "r",
SUM(0)
) as "T1",
LATERAL
(SELECT TRUE as "b"
UNION ALL
SELECT
"r" as "b"
FROM (SELECT 0 ORDER BY COALESCE(0)) as "T1"
) as "T2"
WHERE "b"
po 13. 7. 2020 v 20:06 odesílatel Tom Ellis <
tom-lists-postgresql.org@jaguarpaw.co.uk> napsal:
This small query seems to segfault Postgres. I've tried on the
version of Postgres 11 that comes with Debian Stable and all versions
on https://www.db-fiddle.com/ including 13 (Beta). DB Fiddle actually
says "An unexpected error occurred." but I suspect that's the
segfault.Tom
SELECT
0
FROM (SELECT
TRUE as "r",
SUM(0)
) as "T1",
LATERAL
(SELECT TRUE as "b"
UNION ALL
SELECT
"r" as "b"
FROM (SELECT 0 ORDER BY COALESCE(0)) as "T1"
) as "T2"
WHERE "b"
here is stacktrace
Program received signal SIGABRT, Aborted.
0x00007f269e6e9a25 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
libgcc-10.1.1-1.fc32.x86_64
(gdb) bt
#0 0x00007f269e6e9a25 in raise () from /lib64/libc.so.6
#1 0x00007f269e6d2895 in abort () from /lib64/libc.so.6
#2 0x000000000090340b in ExceptionalCondition
(conditionName=conditionName@entry=0xa55fef "var->varno == rti",
errorType=errorType@entry=0x959029 "FailedAssertion",
fileName=fileName@entry=0xa55f10 "allpaths.c",
lineNumber=lineNumber@entry=3532) at assert.c:67
#3 0x00000000006e3041 in qual_is_pushdown_safe (subquery=0x2b7cc40,
safetyInfo=0x7ffcc3355530, qual=0x2b7a998, rti=6)
at allpaths.c:3532
#4 set_subquery_pathlist (rte=0x2b77258, rti=<optimized out>,
rel=0x2b7a5e0, root=0x2b6fdb0) at allpaths.c:2262
#5 set_rel_size (root=root@entry=0x2b6fdb0, rel=rel@entry=0x2b7a5e0,
rti=rti@entry=6, rte=rte@entry=0x2b77258) at allpaths.c:422
#6 0x00000000006e2101 in set_append_rel_size (rte=0x2b77258, rti=2,
rel=0x2b6e850, root=0x2b798a0) at allpaths.c:1111
#7 set_rel_size (root=root@entry=0x2b6fdb0, rel=rel@entry=0x2b6e850,
rti=rti@entry=2, rte=rte@entry=0x2b68098) at allpaths.c:383
#8 0x00000000006e4ea0 in set_base_rel_sizes (root=<optimized out>) at
allpaths.c:323
#9 make_one_rel (root=root@entry=0x2b6fdb0, joinlist=joinlist@entry=0x2b79f08)
at allpaths.c:185
#10 0x0000000000709b69 in query_planner (root=root@entry=0x2b6fdb0,
qp_callback=qp_callback@entry=0x70a240 <standard_qp_callback>,
qp_extra=qp_extra@entry=0x7ffcc33557a0) at planmain.c:269
#11 0x000000000070edfb in grouping_planner (root=<optimized out>,
inheritance_update=false, tuple_fraction=<optimized out>)
at planner.c:2058
#12 0x0000000000711907 in subquery_planner (glob=glob@entry=0x2b67ac8,
parse=parse@entry=0x2b67be0,
parent_root=parent_root@entry=0x0, hasRecursion=hasRecursion@entry=false,
tuple_fraction=tuple_fraction@entry=0)
at planner.c:1015
#13 0x0000000000712cbb in standard_planner (parse=0x2b67be0,
query_string=<optimized out>, cursorOptions=256,
boundParams=<optimized out>) at planner.c:405
#14 0x00000000007dd4a8 in pg_plan_query (querytree=0x2b67be0,
query_string=query_string@entry=0x2aa23f0 "SELECT\n0\nFROM (SELECT\n
TRUE as \"r\",\n SUM(0)\n ) as \"T1\",\nLATERAL\n(SELECT TRUE
as \"b\"\n UNION ALL\n SELECT\n \"r\" as \"b\"\n
FROM (SELECT 0 ORDER BY COALESCE(0)) as \""...,
cursorOptions=cursorOptions@entry=256, boundParams=boundParams@entry=0x0)
at postgres.c:875
#15 0x00000000007dd5a1 in pg_plan_queries (querytrees=0x2b6fd58,
query_string=query_string@entry=0x2aa23f0 "SELECT\n0\nFROM (SELECT\n
TRUE as \"r\",\n SUM(0)\n ) as \"T1\",\nLATERAL\n(SELECT TRUE
as \"b\"\n UNION ALL\n SELECT\n \"r\" as \"b\"\n
FROM (SELECT 0 ORDER BY COALESCE(0)) as \""...,
cursorOptions=cursorOptions@entry=256, boundParams=boundParams@entry=0x0)
at postgres.c:966
#16 0x00000000007dd8f8 in exec_simple_query (
query_string=0x2aa23f0 "SELECT\n0\nFROM (SELECT\n TRUE as \"r\",\n
SUM(0)\n ) as \"T1\",\nLATERAL\n(SELECT TRUE as \"b\"\n
UNION ALL\n SELECT\n \"r\" as \"b\"\n FROM (SELECT 0
ORDER BY COALESCE(0)) as \""...)
at postgres.c:1158
#17 0x00000000007df755 in PostgresMain (argc=<optimized out>,
argv=argv@entry=0x2ad06e8, dbname=<optimized out>,
username=<optimized out>) at postgres.c:4315
#18 0x00000000007579e9 in BackendRun (port=0x2ac6fe0) at postmaster.c:4523
Regards
Pavel
Tom Ellis <tom-lists-postgresql.org@jaguarpaw.co.uk> writes:
This small query seems to segfault Postgres. I've tried on the
version of Postgres 11 that comes with Debian Stable and all versions
on https://www.db-fiddle.com/ including 13 (Beta). DB Fiddle actually
says "An unexpected error occurred." but I suspect that's the
segfault.
Hm, looks like this has been wrong since we introduced LATERAL :-(.
I pushed a band-aid fix. Thanks for the report!
regards, tom lane
On Mon, Jul 13, 2020 at 08:40:38PM -0400, Tom Lane wrote:
Tom Ellis <tom-lists-postgresql.org@jaguarpaw.co.uk> writes:
This small query seems to segfault Postgres. I've tried on the
version of Postgres 11 that comes with Debian Stable and all versions
on https://www.db-fiddle.com/ including 13 (Beta). DB Fiddle actually
says "An unexpected error occurred." but I suspect that's the
segfault.Hm, looks like this has been wrong since we introduced LATERAL :-(.
I pushed a band-aid fix. Thanks for the report!
Thanks Tom. Could you send a link to the fix? I'd be interested to
see what the problem was.
Tom
