[postgis-tickets] [PostGIS] #4684: concurrent topology construction routine may result in invalid topology

[PostGIS]

#4684: concurrent topology construction routine may result in invalid topology
-----------------------+-------------------
  Reporter:  laopsahl  |      Owner:  strk
      Type:  defect    |     Status:  new
  Priority:  medium    |  Milestone:
 Component:  topology  |    Version:  3.0.x
Resolution:            |   Keywords:
-----------------------+-------------------

Comment (by laopsahl):

 I have been testing the pessimistic approach using this guide line from
 Sandro
     EVERY FACE whos MBR intersects the input line,
     EVERY EDGE having any of those faces on its right or left side,
     EVERY ISOLATED NODE within tolerance distance from the input line ,
 On this branch [https://github.com/larsop/resolve-overlap-and-
 gap/tree/trac_osgeo_org_postgis_ticket_4684] and what ever I tried I ended
 up with st_getFaceGeometry that was null.

 Here I [https://github.com/larsop/resolve-overlap-and-
 gap/commit/7d71dbe9a71f099d2c4a8ec116ba49f7e749dcfb] tested with row-level
 and no change in blocking area and we get null geometry and it seems to
 increase with the number of parallel threads.

 Here I [https://github.com/larsop/resolve-overlap-and-
 gap/commit/8ef48c02587c5aff0f60e4a05339ca82619f9446] extend the blocking
 area and I also did row level lock and that seems to generate less errors,
 but I still get cases where st_getFaceGeometry is null, but fewer.

 It seems like more deadlocks are increasing the cases off null geometries
 from st_getFaceGeometry.

 I will do some more checking around deadlocks and test rollback when that
 happens

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