Horton

Thread

Commits

  1. Cope with lateral references in the quals of a subquery RTE.

  1. Small query using LATERAL that segfaults Postgres

    Tom Ellis <tom-lists-postgresql.org@jaguarpaw.co.uk> — 2020-07-13T17:51:24Z

    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"

  2. Re: Small query using LATERAL that segfaults Postgres

    Pavel Stehule <pavel.stehule@gmail.com> — 2020-07-13T18:27:25Z

    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

  3. Re: Small query using LATERAL that segfaults Postgres

    Tom Lane <tgl@sss.pgh.pa.us> — 2020-07-14T00:40:38Z

    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

  4. Re: Small query using LATERAL that segfaults Postgres

    Tom Ellis <tom-lists-postgresql.org@jaguarpaw.co.uk> — 2020-07-14T09:00:18Z

    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

  5. Re: Small query using LATERAL that segfaults Postgres

    David Rowley <dgrowleyml@gmail.com> — 2020-07-14T09:04:25Z

    On Tue, 14 Jul 2020 at 21:00, Tom Ellis
<tom-lists-postgresql.org@jaguarpaw.co.uk> wrote:
> Thanks Tom.  Could you send a link to the fix?  I'd be interested to
> see what the problem was.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a742ecf9c63d454ccb107a357288c8ec1444ca12

David