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

[Jacek Konieczny]

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ę.

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.

> 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.

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