[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