Dealing with topology data corruption on upgrade to 3.6.0

['Sandro Santilli']

On Wed, Oct 15, 2025 at 03:11:00PM -0400, Regina Obe wrote:
> > https://trac.osgeo.org/postgis/ticket/5983
>
> I'm thinking of a plan that will work as follows to fix.
> 
> 1) roll back the catalog updates, that should fix existing installs without having to restore from a huge backup
> 2) Rename the existing domain and topogeometry type - something like  topogeometry_small
> 3) Create new types (with the existing name, topogeometry, topoelement etc).
> 4) Put in autocasts to topogeometry_small -> topogeometry 

I like the idea of having 2 distinct types so not enforce an on-disk growth
of topologies that do not need large IDs.

> Unfortunately all this kinda breaks our rule of no new functions or
> types in a micro, but I don't see how we have much choice here.

I guess we could consider 3.6 dead and immediately jump on 3.7 if we
don't want to break that rule.

What concerns me most is that what would fix old tables or even just
old records could break new tables or new records. Think about the
situation in which someone added NEW TopoGeometry objects to an existing
table, after the upgrade. Some rows will REALLY have 64bit integers written
on disk and some other will have 32bit integers instead. The only way we MIGHT
have to tell what kind of data is really in what record would be to check the
xmin attribute and compare it the the xmin of the postgis extension version
record.

--strk;

  Libre GIS consultant/developer 🎺
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20251029/41e7bc3f/attachment.sig>