PostGIS BRIN upgrade
Regina Obe
lr at pcorp.us
Mon Jan 13 14:42:54 PST 2025
Tomas,
So we have the PostGIS BRIN upgrade in place now for our master (soon to be
3.6) and our PostGIS 3.5. We are planning to backport to other branches
thru 3.3.
That said, you see anything we might have missed.
I'm most concerned about the upgrade cause we are updating system tables
directly.
We did this to avoid having to drop the opclass and so that users don't need
to reindex their data.
Here is the addition of the inclusion_merge:
https://git.osgeo.org/gitea/postgis/postgis/commit/35706c2dffea7a00f9f5a89c1
4de201401e5f140
The upgrade part starts here. I'm most concerned about this piece
https://git.osgeo.org/gitea/postgis/postgis/src/branch/stable-3.5/postgis/po
stgis_after_upgrade.sql#L281
The steps
If the new inclusion_merge_ops function is missing in the operator class
then do the following:
1) Create a temporary opclass with just the missing function
2) Reassign the generated pg_amproc of this new function to the existing
operator family
3) Fix up the dependency of this new pg_amproc to point at the existing
operator class
4) Drop the autogenerated operator family, which naturally cascades to the
temporary operator class.
I suppose I could have shortened the code by templating it as it's mostly
redundant except for the _inclusion_merge, geometry/geography, and
dimension
I confirmed with this that even with an upgrade the crashes we were seeing
with parallel index build have been resolved and vacuum at least with my big
sample set doesn't trigger any crashes.
I also confirmed old BRIN indexes still work after the upgrade, and you can
add data and they still work, and you can of course create new indexes.
Do you see anything we are missing here?
Thanks,
Regina
More information about the postgis-devel
mailing list