What does
SELECT postgis_full_version();
Run on your current setup vs. your Azure VM setup.
Might thinking is it might be a dependent library crashing.
Usually the issues are with postgis_raster extension since that drags in
GDAL which drags in several more libraries.
Could
Regina,
Thank you so much for your quick response (and for your contributions to the
rest of us in your writings)!
On the physical server I have:
POSTGIS="3.4.2 c19ce56" [EXTENSION] PGSQL="150" GEOS="3.10.2-CAPI-1.16.0"
PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org
Maybe do a search for library dupes / mismatches in your system for the postgis
deps
find / -name “postgis*so”
find / -name “*libgeos*"
find / -name “*libgdal*”
find / -name “*libproj*”
> On Apr 23, 2024, at 10:20 AM, Jeffrey Durrence
> wrote:
>
> Regina,
>
> Thank you so much for your
Greetings,
I am migrating PostgreSQL/PostGIS databases from a physical server with these
specs:
Host OS: Ubuntu 22.04.4 LTS x64 (32GB RAM, 8GB Swap, 1TB disk space, XEON
E5-1660 CPU)
Postgres: 15.6.1-pgdg22.04+1
PostGIS: 3.4.2
To an Azure VM with
Host OS: Ubuntu 22.04.4 LTS x64 (32GB RAM, 8GB
Yah dropping the raster extension if you are not using it would be my first
suggestion.
If you do
DROP EXTENSION postgis_raster;
And it successfully drops, then you definitely don't have data tied to it so
safe to drop before you do your pg_dump and restore.
I've seen people
Regina,
As you suggested, I dropped the postgis_raster extension, exported, and the
imported.
No errors!
Hopefully a record of this will be helpful to others who find themselves in
this situation.
Thanks again for your input!
Jeffrey Durrence
McLean Engineering Company
Jeffrey,
As the output shows, you did not yet upgrade the PostGIS core procedures
on your source data physical server, so it doesn't yet run with the full
upgrade to the latest PostGIS.
Run "SELECT postgis_extensions_upgrade()" against your source database.
Marco
Op 23-4-2024 om 19:20
