Postgres 14 / Postgis 3.2 - Installationsprobleme

Deutsch (German) Installation/Administration
1

Hallo,

ich benutze Open SUSE leap 15.2 seit über einem Jahr ohne Probleme. Jetzt habe ich aber über den normalen Update Mechanismus Postgres 14 mit Postgis 3.2 erhalten. Eine Datenbank konnte ich anlegen, aber wenn ich versuche, die Postgis-Erweiterung mit " CREATE EXTENSION postgis " zu erzeugen, erhalte ich die Fehlermeldung

“konnte Bibliothek /usr/lib/postgresql14/lib64/postgis-3.so« nicht laden /usr/lib/postgresql14/lib64/postgis-.so: undefined symbol: GEOSCoordSeq_copyToBuffer”

Ich bin dann auf Leap 15.3 migriert, in der Hoffnung, die fehlenden Pakate auf diesem Weg zu installieren, aber der Fehler besteht weiter. Ältere Postgres/Postgis-Versionen ( z. b. V12 oder V13) funktionieren aber einwandfrei. Ich vermute daher einen Mismatch in den .so -Bibliotheken von Postgres und Postgis.

Irgendeine Idee, wie sich das lösen lässt ohne “dirty Hacks”?

________________ English: ________________________________________________
I’ve been using Open SUSE leap 15.2 since more than a year without troubles. Recently I receivedPostgres 14.2 together with Postgis 3.2 via the automatic update service of SUSE. I managed to create a V14 database, but when I tried to create the first Postgis extension using " CREATE EXTENSION postgis " I received an error message like this:
“could not load library »/usr/lib/postgresql14/lib64/postgis-3.so« /usr/lib/postgresql14/lib64/postgis-.so: undefined symbol: GEOSCoordSeq_copyToBuffer”

I migrated then to Leap 15.3 hoping that this version would contain the missing library packages but the same error is occurring ever since.

It should be mentioned that I am still running earlier Postgres/Posgis versions ( e. g. V14 / V 3.0.3 ) and this problem is not occurring there. Therefore I believe there is a mismatch of Postgres 14 and Postgis 3.2 libraries.

Any idea how to fix this?

Thanks in advance

2

Hallo,

nach dem wahrhaft überwältigenden Support hier ( 0 von 357 möglichen Tips … ) musste ich mir selber helfen und war dann mit einer “Brute Force” - Aktion schließlich erfolgreich. Fuer alle, die auch in Zukunft das neueste Postgres und das neueste Postgis unter OpenSuse nutzen wollen, hier mal die Kurzfassung:

erstmal alle standardmäßig installierten Yast-Pakete von Postgis deinstallieren

sämtliche alten Geos-Bibliotheken deinstallieren und nur die neueste ( bei mir war das 3.10 ) installieren

Sich das neueste Postgis-Bundle (3.2.1 ) holen:
https://postgis.net/2021/12/18/postgis-3.2.0/

README.postgis genau lesen und beim ersten Schritt “./configure” die Schalter benutzen, die man wirklich braucht

vor dem Installieren folgendes wichtiges Postgres-Tool installieren, das der automatische Yast-Update leider nicht mit liefert. Da müsst Ihr in Eurer Distribution schauen:
rpm -qf /usr/bin/pg_config

bei war es in postgresql14-server-devel-14.2-lp153.27.2.x86_64

Tut man das nicht, läuft die gesamte Installation sehr rasch ins Leere.

Bei der Installation nicht den Standard C-Compiler verwenden, den Suse in der Grundinstallation liefert, sondern genau den , der beim ersten Aufruf von ./configure gesucht wird ( war bei mir im Yast dann sogar zu finden )

bei ./configure genau die Protokolle im Auge behalten, ob es auch wirklich alle Voraussetzungen für das anschließende Make gefunden hat

nach make und anschliessend hoffentlich vollständigem Durchlauf auch “make check” laufen lassen. Bei mir hat es da sehr minutiös - aber auch sehr lange! - die wichtigsten Postgis ST-Funktionen verifiziert

erst wenn das zufriedenstellend durchgelaufen ist: make install

und schwuppdiwupp - kaum hat man mal 3 Stunden spendiert, schon funktioniert endlich auch das so wichtige SQL-Kommando “create extension postgis” wieder

Fazit:

Ich habe bei OpenSuse Leap 15 bisher alle Generationen von 15.0 bis 15.3 durchlaufen. Aber das war jetzt das erste Mal, dass mich Yast und der automatische Softwareupdate so grob im Stich gelassen haben. Ich weiß nicht, ob hier im Forum auch Suse-Entwickler ab und zu mal reinschauen. Falls ja - das wäre doch mal ein Kandidat für einen Upgrade bei der Yast-/Zypper-Konfiguration …

3

@Betzefreund:

Moment mal! – wenn wir über „PostGIS” und, das Paket „postgresql14-postgis-3.2.1-lp153.14.1.x86_64.rpm” reden dann, folgendes –

Irgendwann, wird der Leuenberger’s Dominique es in Griff kriegen und, Du wirst ein passende PostgreSQL Erweiterung bekommen.

4

Danke für den Hinweis,

ist mir auch lieber so. Ich hätte keine Lust gehabt, das ganze bei jedem Major Releasewechsel zu wiederholen …

CU

5

War das Einspielen dieser Softwareupdates wegen Sicherheitslücken zwingend erforderlich? Wenn nein, weshalb macht man nicht einfach ein Downgrade der problematischen Softwarepakete (RPM)? Siehe dazu die “RPM-Downgrade”-Hinweise unter:
https://forums.opensuse.org/showthread.php/568621-GRUB-reagiert(e)-extrem-träge?p=3120211#post3120211

Und in Zukunft empfehle ich den Einsatz des vollautomatischen Software-Updateverfahren, welches nur Sicherheitsupdates installiert (auch Seite 2 beachten!) und unter:
https://forums.opensuse.org/showthread.php/547458-Softwareupdates-(im-Allgemeinen)
vorgestellt wurde. Dieses Softwareupdateverfahren hat sich jetzt über ein Jahr auf mehreren Rechnern mit SLED15 bewährt.

Mit OpenSUSE Leap wurde der Produktlebenszyklus von SUSE Linux Enterprise (SLE) übernommen.
https://en.opensuse.org/Lifetime

Gemäss Kapitel 2.2 des Upgradehandbuchs von SUSE Linus Enterprise Desktop (SLED) hat der/die AdministatorIn bei einem Minor-Upgrade, zum Beispiel OpenSUSE Leap 15.3 auf 15.4, 6 Monate Zeit das Minor-Upgrade auf allen Rechnern (der Produktivumgebung) durchzuführen und bei Problemen mit einzelnen Softwarepaketen (RPM) die erforderliche Problembehebung beim Softwareentwickler einzufordern. Solange nicht alle durch das Upgrade ausgelösten, relevanten Probleme (in der Testumgebung nachweislich) behoben wurden, sollte der Administrator mit dem Einspielen des Upgrades auf der Produktivumgebung abwarten.
https://documentation.suse.com/de-de/sled/15-SP3/html/SLED-all/cha-upgrade-background.html#sec-upgrade-background-life-cycle

Generell empfehle ich den Einsatz und die Pflege eines Betriebssystems gemäss den Angaben unter:
https://forums.opensuse.org/showthre…83#post3114383

https://forums.opensuse.org/showthread.php/568621-GRUB-reagiert(e)-extrem-träge?p=3120211#post3120211

Konkret darf die Veröffentlichung von OpenSUSE Leap 15.4 (und SLE15 Service Pack 4) im Juni 2022 erwartet werden. Somit hat jeder Administrator und jede Administratorin bis Ende November 2022 Zeit, das Minor-Upgrade von OpenSUSE Leap 15.3 auf 15.4 durchzuführen (respektive SLE15 SP3 auf SP4).

6

"War das Einspielen dieser Softwareupdates wegen Sicherheitslücken zwingend erforderlich? "

Ich kenne mich nicht so aus mit dem Entwickler- und Administratoren-Jargon hier, deshalb zur Sicherheit mal noch so viel:

Meine Probleme hatten nichts mit dem Umstieg von Leap 15.2 auf 15.3 zu tun. Die Inkompatibilität von Postgres 14.2 und Postgis 3 trat schon bei Leap 15.2 auf. Eingehandelt hatte ich sie mir über den automatischen Software-Update, der einem regelmäßig neue Release-Pakete anbietet und diese auch selber installiert. Das da was nicht stimmte, hatte ich auch erst mit der Neuerstellung einer Postgres 14.2-Datenbank und den anschließenden Befehlen “create extension…” bemerkt.

Meine manuellen Updates habe ich erst gemacht, als klar war, dass der automatische Software-Update in die Hose gegangen war.

Die Hinweise auf die neueren Postgres-/Postgis-Releases habe ich gelesen, aber nur Bahnhof und Abfahrt verstanden …