[postgis-tickets] [PostGIS] #4776: st_geometrytype causes 100% CPU loop in postgres13 on specific linestring

PostGIS trac at osgeo.org
Sun Nov 1 02:43:43 PST 2020


#4776: st_geometrytype causes 100% CPU loop in postgres13 on specific linestring
-------------------------+---------------------------
  Reporter:  tvijlbrief  |      Owner:  pramsey
      Type:  defect      |     Status:  new
  Priority:  blocker     |  Milestone:  PostGIS 3.0.3
 Component:  postgis     |    Version:  3.0.x
Resolution:              |   Keywords:
-------------------------+---------------------------

Comment (by tvijlbrief):

 I also tried it with current Postgis master (3.1) and it does fail again
 with a Debian postgres13 docker base image. Looking at the Postgis source
 I cannot think of a reason why this particular linestring fails with
 st_geometrytype() and works OK with eg st_numpoints().

 The only difference is that st_numpoints() fetches the whole TOAST object
 and st_geometrytype() just requests a slice at the front of the TOAST
 object. This looks to me like a low level issue with Postgres13 and TOAST
 objects of a specific size and or compression behavior.

 I have monitored https://www.postgresql.org/list/pgsql-bugs/2020-10/ to
 see if a generic Postgres13 issue popped up, but it did not, so I decided
 to start with reporting this as a Postgis issue. Perhaps we should report
 this issue as a PostgreSQL-13 issue referring to this ticket?

 It's a strange issue, also because it does not effect MacOS with this
 specific instance, and most LineStrings work just OK. I was very relieved
 to see that @robe could reproduce the error.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4776#comment:7>
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.


More information about the postgis-tickets mailing list