[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