[packages/postgresql: 2/3] - initial support for full pg_upgrade - exmaple: pg_upgrade -b /usr/lib64/postgresql-9.1/bin/ -B /us

[Andrzej Zawadzki]

On 27.09.2012 15:39, Jacek Konieczny wrote:
> On Thu, Sep 27, 2012 at 03:21:12PM +0200, Jakub Bogusz wrote:
>> On Tue, Sep 25, 2012 at 12:29:38PM +0200, zawadaa wrote:
>>> commit 9214a4d4c6913380a9e02edb10cf81acca08ee45
>>> Author: Andrzej Zawadzki <zawadaa w pld-linux.org>
>>> Date:   Tue Sep 25 12:22:51 2012 +0200
>>>
>>>     - initial support for full pg_upgrade
>>>     - exmaple:
>>>     pg_upgrade -b /usr/lib64/postgresql-9.1/bin/ -B /usr/bin/ -d /var/lib/pgsql/data -D /var/lib/pgsql/data_new
>>>     - I don't know is this propoer packaging - looks ugly - please review
>>>     - NOTE: this can upgrade from 9.1 to 9.2 only!
>> Parę pytań.
>> Co dokładnie jest potrzebne pg_upgrade ze starej wersji postgresql-a?
> Binarka serwera i wszystkich modułów (w tym zewnętrznych) które były
> używane przez upgrejdowaną bazę.
Dokładnie. Zalecane żeby wersja postgresa dla pg_upgrade była możliwie
identyczna z tą na której działała klaster.
>
> Ten pg_upgrade działa tak, że uruchamia stary i nowy postgresql (na
> zmiane) i dane z jednego przesyła do drugiego. Niespecjalnie mi się to
> podoba, ale to na razie najlepsze co PostgreSQLowcy wymyślili.
Jacku chyba nie do końca tak: uruchamia dwa serwery na różnych portach.
Najlepsze ;-) dziwadło ;-)
BTW: u mnie pg_upgrade ma wynik 52 minuty. Dla kontrastu dump/restore
trwa 10h...
>> Czy obsługuje tylko poprzednią wersję, czy także wcześniejsze?
> „pg_upgrade supports upgrades from 8.3.X and later to the current major
> release of PostgreSQL, including snapshot and alpha releases.”
>
> Więcej tu: http://www.postgresql.org/docs/9.0/static/pgupgrade.html
>
>> Mi też się nie podoba ten sposób budowania. Z tego co widzę - pg_upgrade
>> do zbudowania nie potrzebuje niczego ze starszej wersji postgresql-a
>> - więc nie ma powodu, żeby budować ją jednocześnie.
> Racja.
>
>> Widziałbym raczej postgresql9.1.spec (ew. też postgresql9.0.spec itd.,
>> w ramach wersji obsługiwanych przez pg_upgrade) - i stamtąd budowany
>> pakiet np. %{name}-upgradesource czy %{name}-dump (w zależności od tego,
>> co to naprawdę robi), ew. jakieś inne podpakiety, jeśli ktoś potrzebuje.
> Najlepiej byłoby móc zachować binarki z poprzedniego buildu - bo tego
> właściwie oczekuje pg_upgrade… ale nie widzę jak to by miało działać
> z dystrybucyjnymi pakietami (zależnościami ciągniętymi przez upgrade).
>
> Myślę, że najrozsądniej byłoby gdy wychodzi nowy postgresql robić tak:
>
> kopia pakietu postgresql -> postgresqlX.Y
> tam ustawiony inny %{_prefix}
> i tak budowane
>
> Najlepiej od razu dodać bconda do speca, żeby budował z innym
> %{_prefix} (np. /usr/lib/postgresql-old} i pomijał niepotrzebne
> pliki/podpakiety. Wtedy pozostaje skopiowanie pakietu pod nową nazwą
> puszczenie budowania z bcondem.

Faktycznie najlepiej byłoby dorobić to do każdego z branchy POSTGRESQL-X_X
i tam budować dwa razy - "normalny" pakiet i ten dla pg_upgrade ze
zmienionym prefiksem.
Domyślnie bcond byłby wyłączony - np. teraz dla 9.2 nie ma potrzeby
budować, ale przy
wejściu na 9.3 można by włączyć.

Jak tak może być to postaram się dorobić.
>
> Alternatywnie bcond by pakował, zamiast standardowego zestawu pakietów:
> %package -n postgresql%{version}
> z plikami serwera w innym katalogu. Wtedy można by to z jednego speca, 
> z brancha na buildery słać. Ale wtedy automatyka FTPowa będzie krzyczeć,
> że z różnych wersji src.rpm pakiety są.
>
> Pozdrowienia,
>         Jacek
>
-- 
Andrzej Zawadzki