Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#4916 closed defect (fixed)

st_asgeobuf() with WINDOW PARTITION crashes server

Reported by: Robins Owned by: pramsey
Priority: blocker Milestone: PostGIS 3.1.4
Component: postgis Version: 3.0.x
Keywords: st_asgeobuf Cc:


When I use st_asgeobuf() with WINDOW PARTITION it crashes server. Here is a simple example.

$ psql
psql (13beta2, server 13.3)
Type "help" for help.

regression=> \x
Expanded display is on.

regression=> \dx postgis
List of installed extensions
-[ RECORD 1 ]--------------------------------------------------------------------
Name        | postgis
Version     | 3.0.3
Schema      | public
Description | PostGIS geometry, geography, and raster spatial types and functions

regression=> \x
Expanded display is off.
regression=> SELECT public.st_asgeobuf(NULL::pg_class, version()) over (partition by RANDOM());
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!?> \q

Change History (12)

comment:1 by Robins, 3 years ago

2 other Tickets, with similar (WINDOW PARTITION) crashes… may be they're related.

comment:2 by pramsey, 3 years ago

Milestone: PostGIS

comment:3 by pramsey, 3 years ago

Milestone: 3.1.3PostGIS 3.1.3

Milestone renamed

comment:4 by robe, 3 years ago

Milestone: PostGIS 3.1.3PostGIS 3.1.4

In prep for 3.1.3 release

comment:5 by robe, 3 years ago

Priority: mediumblocker

comment:6 by robe, 3 years ago

Confirmed crashes on PostGIS 3.1.3 against PostgreSQL 14beta2.

Backtrace looks like:

Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) cont
[Thread 6848.0x433c exited with code 0]

Thread 1 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6848.0xf44]
pg_detoast_datum (datum=0x0) at fmgr.c:1724
1724            if (VARATT_IS_EXTENDED(datum))
(gdb) bt
#0  pg_detoast_datum (datum=0x0) at fmgr.c:1724
#1  0x000000006f004ead in pgis_asgeobuf_transfn (fcinfo=0x520e990)
    at lwgeom_out_geobuf.c:75
#2  0x000000000064a2f1 in advance_windowaggregate (
    winstate=winstate@entry=0x533b0a8, perfuncstate=0x84fb2f0,
    peraggstate=0x84fb140) at nodeWindowAgg.c:345
#3  0x000000000064e15b in eval_windowaggregates (winstate=0x533b0a8)
    at nodeWindowAgg.c:964
#4  ExecWindowAgg (pstate=0x533b0a8) at nodeWindowAgg.c:2207
#5  0x000000000060c5ba in ExecProcNode (node=0x533b0a8)
    at ../../../src/include/executor/executor.h:257
#6  ExecutePlan (execute_once=<optimized out>, dest=0x84a3630,
    direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>,
    operation=CMD_SELECT, use_parallel_mode=<optimized out>,
    planstate=0x533b0a8, estate=0x533ae70) at execMain.c:1551
#7  standard_ExecutorRun (queryDesc=0x84b5aa0, direction=<optimized out>,
    count=0, execute_once=<optimized out>) at execMain.c:361
#8  0x00000000007bfc7b in PortalRunSelect (portal=portal@entry=0x52dc590,
    forward=forward@entry=true, count=0, count@entry=2147483647,
    dest=dest@entry=0x84a3630) at pquery.c:919
#9  0x00000000007c195c in PortalRun (portal=portal@entry=0x52dc590,
    count=count@entry=2147483647, isTopLevel=isTopLevel@entry=true,
    run_once=run_once@entry=true, dest=dest@entry=0x84a3630,
    altdest=altdest@entry=0x84a3630, qc=qc@entry=0x520f360) at pquery.c:763
#10 0x00000000007ba13b in exec_simple_query (
    query_string=0x53141e0 " SELECT public.st_asgeobuf(NULL::pg_class, version()                                                                ) over (partition by RANDOM());") at postgres.c:1214
#11 0x00000000007bd998 in PostgresMain (argc=argc@entry=1,
    argv=argv@entry=0x520f980, dbname=<optimized out>,
    username=0x1d8c10 "postgres") at postgres.c:4486
#12 0x000000000071faa1 in BackendRun (port=0x520f7b0, port=0x520f7b0)
    at postmaster.c:4507
#13 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x1d6b00)
    at postmaster.c:5020
#14 0x0000000000963c73 in main (argc=3, argv=0x1d6b00) at main.c:186

comment:7 by robe, 3 years ago

It looks like this doesn't even need OVER() to crash.

This does it too

 SELECT ST_AsGeoBuf(NULL::pg_class, version()) ;

comment:8 by pramsey, 3 years ago

This crash appears to be related to passing in the NULL argument, not to the finalfn behaviour. I can use window functions fine, as long as I pass in a non-null argument.

SELECT public.st_asgeobuf(t, 'g') over (order by RANDOM())
FROM (VALUES ('POINT(0 0)'::geometry, 'A0006', 300), 
             ('POINT(1 1)'::geometry, 'A0006', 302)) t(g, a, b);

comment:9 by Paul Ramsey <pramsey@…>, 3 years ago

In ef2995b/git:

Fix crashes in aggregate functions, references #4916, #4770, #4724, #4916

comment:10 by Paul Ramsey <pramsey@…>, 3 years ago

In 22dec99/git:

Fix crashes in aggregate functions, references #4916, #4770, #4724, #4916

comment:11 by pramsey, 3 years ago

Resolution: fixed
Status: newclosed

comment:12 by Paul Ramsey <pramsey@…>, 3 years ago

In 5548ad23/git:

Repair crashes in raster aggregates, references #4916, #4770, #4724, #4916

Note: See TracTickets for help on using tickets.