[PostGIS] #5983: Potential data corruption in topology.topoelement after upgrade to 3.6.0

PostGIS trac at osgeo.org
Wed Sep 10 17:29:33 PDT 2025


#5983: Potential data corruption in topology.topoelement after upgrade to 3.6.0
-----------------------+---------------------------
  Reporter:  packi     |      Owner:  robe
      Type:  defect    |     Status:  new
  Priority:  blocker   |  Milestone:  PostGIS 3.6.1
 Component:  topology  |    Version:  3.6.x
Resolution:            |   Keywords:
-----------------------+---------------------------
Comment (by robe):

 Replying to [comment:4 strk]:
 > I bet on DatumGetInt64 reading past the int32 data, which is what I was
 asking about in
 https://gitea.osgeo.org/postgis/postgis/pulls/242#issuecomment-13471
 >
 > Hopefully Ayorinde can look at this. We might need to force rewrite of
 all TopoElement columns

 that wouldn't explain though why


 {{{
 SELECT t[1], t[2] FROM postgis_test;
 }}}


 gives garbage results would it?  After all topoelement is just a domain
 type over bigint[] (prior to that over int[]).  The above query just uses
 PostgreSQL plumbing, none of our plumbing. But you might be right that we
 need to rewrite topoelement columns, though I think its rare people
 actually store topoelements as columns.  Aren't those more for convenience
 of our functions and the real meat would be in the edges/nodes/faces and
 topogeometry columns.

 But I'm still guessing we missed something when updating the system
 catalogs to change the domain base type because we couldn't change that
 without dropping the domain using ALTER DOMAIN command.
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5983#comment:5>
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