[postgis-tickets] [PostGIS] #4821: PostGIS 3.1 + Postgres 13 MVT crash

[PostGIS]

#4821: PostGIS 3.1 + Postgres 13 MVT crash
---------------------+---------------------------
 Reporter:  komzpa   |      Owner:  pramsey
     Type:  defect   |     Status:  new
 Priority:  medium   |  Milestone:  PostGIS 3.1.0
Component:  postgis  |    Version:  2.5.x
 Keywords:           |
---------------------+---------------------------
 {{{

 [22:32] <Komzpa> Huston we have a problem
 [22:32] <Komzpa>
 https://gist.github.com/Komzpa/c5f1b970d45cd3aa11e4efc60c38295d
 [22:34] <Komzpa> that might be because of mix of a debian postgres +
 ubuntu postgis, let me revert both to ubuntu pgdg and recheck
 [22:34] <strk> doesn't tell much, did you look at that line in postgresql
 sourcecode ?
 [22:37] <Komzpa>
 https://github.com/postgres/postgres/blob/master/src/backend/executor/execExpr.c#L3214
 [22:37] <Komzpa> Assert(as->d.agg_strict_input_check.jumpnull == -1);
 [22:41] <Komzpa> the only aggregate in the query is ST_AsMVT(q, 'stats',
 8192, 'geom')
 [22:46] <RhodiumToad> that's ... not good
 [22:47] <Komzpa> 22:46:02 [gis] > select ST_AsMVT(q, 'stats', 8192,
 'geom') from (select 1 as id, 'POINT (0 0)' as geom) q;
 [22:47] <Komzpa> ERROR:  XX000: Unknown geometry type: 0 - Unknown
 [22:47] <Komzpa> LOCATION:  pg_error, lwgeom_pg.c:250
 [22:47] <Komzpa> Time: 0,610 ms
 [22:47] <Komzpa> 22:46:15 [gis] > select ST_AsMVT(q, 'stats', 8192,
 'geom') from (select 1 as id, 'POLYGON(1 1, 3 3, 4 0, 1 1)' as geom) q;
 [22:47] <Komzpa> ERROR:  XX000: Unknown geometry type: 857748256 - Invalid
 type
 [22:47] <Komzpa> LOCATION:  pg_error, lwgeom_pg.c:250
 [22:47] <Komzpa> Time: 0,634 ms
 [22:47] <Komzpa> does not look expected to me
 [22:48] <Komzpa> no, going back and syncing versions does not help
 [22:48] <RhodiumToad> I don't think that's relevant to your failed
 assertion
 [22:49] <Komzpa> the spot is the same
 [22:49] <RhodiumToad> this looks like an oversight in the code?
 [22:49] <Komzpa> I mean, it's a minimized example of my query that's
 already misbehaving
 [22:49] <Komzpa> but not yet to a crash
 [22:49] <RhodiumToad> right, but if my guess is right, the crash depends
 on amount of data
 [22:50] <RhodiumToad> since it's related to aggregate
 serialize/deserialize functions, which are used in parallel aggregation
 [22:51] <RhodiumToad> you're testing on 13.1?
 [22:53] <Komzpa> yes
 [22:57] <Komzpa> RhodiumToad: does this sound like postgis or postgres
 issue?
 [22:57] <RhodiumToad> Komzpa: does that aggregate function have a
 deserialize function that is not declared as strict?
 [22:58] <RhodiumToad> my initial suspicion (not confirmed) is that it's a
 postgres issue, but triggered by the presence of a non-strict deserialize
 function (all the builtin deserialize functions are strict)
 [22:58] <Komzpa> yes, since PostGIS 2.5.0
 https://github.com/postgis/postgis/blob/8b13c3e2f8366d902dbf516ec17de09ae84361f4/postgis/postgis.sql.in#L4836
 [22:59] <Komzpa> it was working okayish before postgis 3.1 upgrafe
 [23:02] <Komzpa> 23:02:45 [gis] > alter function pgis_asmvt_deserialfn
 strict;
 [23:03] <Komzpa> RhodiumToad: as I understand that is expected to help?
 [23:06] <RhodiumToad> well it might break the handling of nulls, depending
 on how the other funcs for the aggregate are written
 [23:07] <RhodiumToad> ... did it make any difference?
 [23:08] <Komzpa> tonight there was crash on second 2, now job runs for 5
 minutes finely already
 [23:08] <Komzpa> so at least it helped the crash
 }}}

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4821>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.