Opened 3 years ago

Closed 2 years ago

#5122 closed defect (wontfix)

Crash on aurora postgres topology add_polygon

Reported by: robe Owned by: robe
Priority: medium Milestone: PostGIS 3.1.6
Component: topology Version: 3.1.x
Keywords: Cc:

Description (last modified by robe)

The performance suite is failing on aurora postgres in a couple of cases.

In the topology case it crashes

https://git.osgeo.org/gitea/postgis/postgis-performance

POSTGIS="3.1.5 0" [EXTENSION] PGSQL="130" GEOS="3.9.1dev-CAPI-1.14.1" PROJ="6.2.1" LIBXML="2.9.9" LIBJSON="0.12.99" LIBPROTOBUF="1.3.0" WAGYU="0.5.0 (Internal)"
[02:59:23] pgtap/topology/add_polygon.sql .......
1..3
16
psql:pgtap/topology/add_polygon.sql:13: server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
psql:pgtap/topology/add_polygon.sql:13: fatal: connection to server was lost
Dubious, test returned 2 (wstat 512, 0x200)
Failed 3/3 subtests

The add_linestring was okay except for exceeding time limits

data

CREATE EXTENSION postgis_tiger_geocoder CASCADE;
CREATE EXTENSION topology;

Load data with psql from Where state boundaries are the ones in - http://postgis.net/extra/test-data/tiger_national.sql.bz2

Test

SELECT topology.CreateTopology('topoperf', 4269) ;
CREATE TABLE topoperf.polygon
AS SELECT (ST_Dump(geom)).geom AS g FROM (SELECT the_geom AS geom FROM tiger.state) AS f;

SELECT topology.TopoGeo_addPolygon('topoperf', g)
  FROM topoperf.polygon;

I tested on RDS running and that passed fine including the timing

POSTGIS="3.1.4 ded6c34" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.2" PROJ="8.0.1" LIBXML="2.9.1" LIBJSON="0.15" LIBPROTOBUF="1.3.2" WAGYU="0.5.0 (Internal)" TOPOLOGY

I'm going to isolate further and check other systems.

Change History (4)

comment:1 by robe, 3 years ago

I should add, to rule out 3.1.5 as the culprit, I built on my mingw 3.1.5 and tested against 3.1.5, and that worked fine. So I'm suspecting it's my sizing of aurora instance I screwed up or something about the aurora special storage structure causing the issue.

comment:2 by robe, 3 years ago

Okay further investigation, it is not crashing at the building of topology it seems but instead on the ROLLBACK.

Taking out the commit/rollback on my test Aurora, it completes in 2 hrs. On RDS it completes in about 10-11 minutes. Working with Amazon engineer to troubleshoot the issue further.

So this actually works, my mistake:

SELECT topology.CreateTopology('topoperf', 4269) ;
CREATE TABLE topoperf.polygon
AS SELECT (ST_Dump(geom)).geom AS g FROM (SELECT the_geom AS geom FROM tiger.state) AS f;

SELECT topology.TopoGeo_addPolygon('topoperf', g)
  FROM topoperf.polygon;

But the test is really doing more like below which crashes

BEGIN TRANSACTION;
SELECT topology.CreateTopology('topoperf', 4269) ;
CREATE TABLE topoperf.polygon
AS SELECT (ST_Dump(geom)).geom AS g FROM (SELECT the_geom AS geom FROM tiger.state) AS f;

SELECT topology.TopoGeo_addPolygon('topoperf', g)
  FROM topoperf.polygon;

ROLLBACK;

So I am guessing it is how the Aurora storage engine works (since that is what makes it a fork the plumbing under the storage engine) something it doesn't like. I think I have just one reader node in addition to the writer, where as RDS has no extra nodes to contend with.

comment:3 by robe, 3 years ago

Description: modified (diff)

comment:4 by robe, 2 years ago

Resolution: wontfix
Status: assignedclosed

I think instead of crashing it was just timing out. Going to close this for now to get it out of the way, as no luck debugging the issue.

Note: See TracTickets for help on using tickets.