Jak zrobić upgrade postgresql 9.6 do 14 na debianie

Hejka,

Jak zwykle moja "surowa" przyjaźń z linuxem wychodzi mi bokiem. Zrobiłem migracje kilku baz z 9.6 do 14 na windows bez najmniejszych problemów. Wszystko przeszło bezproblemowo. Niestety na linuxie pg_upgrade ciągle wali błędami, a to nieprawidłowa konfiguracja, a to brak plików, a to coś tam... poprawiłem już kilkanaście sytuacji i doszedłem do takiego błędu:

Your installation references loadable libraries that are missing from the
new installation. You can add these libraries to the new installation,
or remove the functions using them from the old installation. A list of
problem libraries is in the file:
loadable_libraries.txt

w pliku loadable_libraries.txt wymienione są języki: pltcl, plperl i plpython2u

co ciekawe na postgresie 9.6 te dodatkowe języki są zainstalowane więc w systemie to wszystko jest tylko prawdopodobnie 14 nie ma odpowiednio ustawionych ścieżek do tego ale moja wiedza w tym zakresie chyba się wyczerpała. Ponowny apt-get install nie pomógł wiec pytania do was drodzy forumowicze jak mam wykonać ten pg_upgrade? Jak powiedzieć postgresq 14 gdzie są zainstalowane te biblioteki do pythona itd? Podpowiecie coś?

Nie robiłem takiej aktualizacji, ale z tego co napisałeś wygląda że dwie wersje pg się gryzą na Linuksie jeśli są zainstalowane jednocześnie.
Upgrade w stylu pg_upgrade jest nietypowy dla baz danych (podmianka binarek zamiast pg_dump / pg_restore).
Może i jest wygodniejszy ale ryzykowny.

Tutoriali do pg_upgrade znajdziesz pewnie multum, tu masz taki bardziej strategiczny niż taktyczny:

• A Primer on PostgreSQL Upgrade Methods

A moze Docker?

Nie możesz tego zrobić przez backup i restore? Najbezpieczniejsza opcja - chociaż wiadomo - dłużej zajmuje.

Możesz zrzucić wszystkie bazy danych dumpem (pg_dumpall -U postgres > dump_all_db) do jednego wielkiego pliku, a potem odtworzyć przez pg_restore już na nowej wersji serwera.

Jak nie ogarnę tych dodatkowych jezykow to przy restore dostane błąd i baza nie będzie działać poprawnie

Wydaje mi się, że kiedyś przy jakiejś zabawie/testach mogłem mieć ten lub bardzo podobny problem. Trzeba było zaktualizować rozszerzenia do najnowszej wersji na starszej wersji silnika. Zobacz to https://serverfault.com/questions/849110/upgrade-postgresql-9-5-to-9-6-with-postgis-pg-upgrade
Poradę traktuj nie jako pewnik bo ja taką aktualizację robiłem na lokalnym developmentowym środowisku a nie na "poważnej bazie".

No to prawie wszystko ogarnąłem ...
z PLTCL i PLPerl poradziłem sobie dość prosto:
pltcl
plperl
wystarczył apt-get install i potem create extension.

Problem niestety jest z PLPython2u...
Na powyższych stronach znalazłem tylko python 3 natomiast tutaj znalazłem informacje:
https://postgrespro.com/list/thread-id/2517911
że od postgresa 13 wycofują się z pythona 2 :( smuteczek. Rozwiązaniem na teraz jest przerobienie funkcji używająych pythona 2 w obecnych bazach na pythona 3 spróbowanie ponownie już z python 3 (który na 14 doinstalował mi się jak perl i tcl)

Nawiasem mówiąc to masz chyba sporo logiki biznesowej po stronie bazy, skoro korzystasz z tylu języków skryptowych.

Ja tak kiedyś robiłem, ale się oduczyłem. Jest o wiele mniej problemów kiedy mamy całą logikę w aplikacji a baza to tylko magazyn na dane i nic więcej.

Chociażby debugowanie, testowanie jest bardzo utrudnione. Podobnie problemy jakie masz teraz, lub sytuacja kiedy trzeba zmienić silnik bazy danych.

No dobra aktualizacja z 9.6 do 14 przebiegła pomyślnie.

Niestety musiałem na jednej z baz przepisać kod z plpython2u na plpython3u (dosłownie kilka linii zmienionych) ale po tej operacji przeszło wszystko bez najmniejszych problemów samym pg_upgrade.

@TomRZ: logika w bazie ma swoje wady i zalety. W moim konkretnym przypadku zalet było więcej aczkolwiek niektóre bazy to 2013 więc od tego czasu w IT sporo się pozmieniało. Jak sami widzicie przejście z 9.6 do 14, a ostatnią taką migrację robiłem z 9.3 do 9.6 :)

Zaleta logiki po stronie bazy jest właściwie tylko jedna, czyli wydajność: całość dzieje się po stronie bazy, jest mniej komunikacji między aplikacją, a DB.

To właściwie jedyna taka generalna zaleta, za to jest sporo wad. Kiedyś to w innym miejscu dokładniej analizowałem, i tych wad wyszło całkiem sporo, więcej niż tutaj wymieniłem.