[PostGIS] #5983: Data corruption in topology.topoelement and topology.topogeometry after upgrade to 3.6.0

PostGIS trac at osgeo.org
Wed Oct 29 17:40:26 PDT 2025


#5983: Data corruption in topology.topoelement and topology.topogeometry 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:22 strk]:
 > Replying to [comment:19 francoisb]:
 > > FWIW, in my database (PostgreSQL 16.10, macOS), I was able to recover
 the topogeometry columns with these two steps:
 > >
 > > 1) Upgrade the topology to use the bigint feature:
 > >
 > > {{{
 > > SELECT UpgradeTopology('topo_1');
 > > }}}
 >
 > Wow, I did't even notice the existance of this function, I don't like
 the name of it :(
 > For those like me who missed it, its documentation is here:
 https://postgis.net/docs//en/UpgradeTopology.html
 >
 > I dunno why we call it an "upgrade" to get a bigger size :/
 >
 > > Note I'm not 100% sure this step is actually needed, but I add it here
 because I did it. We could test without, and perhaps remove it.
 > >
 > > 2) Recover `id` and `type` values from the bytes of corrupted `id`,
 with a query like:
 > >
 > > {{{
 > > UPDATE table_1
 > > SET
 > >   topogeom = (
 > >     (topogeom).topology_id,
 > >     (topogeom).layer_id,
 > >     (topogeom).id & 0xFFFFFFFF, -- 32 least significant bits from
 corrupted "id"
 > >     (topogeom).id >> 32         -- 32 most significant bits from
 corrupted "id"
 > >   )::topogeometry
 > > WHERE topogeom IS NOT NULL
 > > RETURNING topogeom;
 > > }}}
 >
 > Nice one, it might be time to start a PR with this code made available
 as a repair function so to provide improvements as we see them (like maybe
 check the xmin against the postgis xmin...). Would you be up for such task
 ? Then I'll be happy to test it against my existing corrupted tables as
 right now I cannot even `pg_upgrade` a cluster due to this bug,
 apparently.


 Wouldn't you end up overupdating with that.  I was thinking more like

 {{{
  UPDATE table_1
  SET
    topogeom = (
      (topogeom).topology_id,
     (topogeom).layer_id,
      (topogeom).id & 0xFFFFFFFF, -- 32 least significant bits from
 corrupted "id"
      (topogeom).id >> 32         -- 32 most significant bits from
 corrupted "id"
    )::topogeometry
  WHERE (  (topogeom).id & 0xFFFFFFFF ) <> (topogeom).id;


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