postgresql 7.3 dla Ra (pack?)

[Jakub Bogusz]

On Fri, Mar 21, 2003 at 07:05:03PM +0100, Tomasz Kłoczko wrote:
> On Wed, 19 Mar 2003, Jakub Bogusz wrote:
> > On Wed, Mar 19, 2003 at 05:25:57PM +0100, Tomasz Kłoczko wrote:
> > > On Wed, 19 Mar 2003, wrobell wrote:
> > > > On Wed, Mar 19, 2003 at 12:26:00AM +0100, Bartłomiej Ogryczak wrote:
> > > > > wrobell wrote:
> > > > > >>>IMHO... Prace powinny się skupić nad nową wersją dystrybucji...
> > > > > >>Czyli czynisz założenie, że PLD do niczego poważnego się nie nadaje
> > > > > >>i nie powinno nadawać?
> > > > > >Nic takiego nie napisałem.
> > > > > 
> > > > > Ale rezygnacja z security updates dla starszych wersji by
> > > > > dokładnie coś takiego znaczyła.
> > > > 
> > > > Update do 7.3, IMHO, nie jest li tylko security update.
> > > 
> > > Dotąd nie śledziłem za mocno watku. Czy naprawdę nie ma tej sec poprawki 
> > > dla 7.2 ?
> > 
> > Nie ma. Nawet gdyby była, wymagałaby zrobienia tego, co przy upgrade do
> > 7.3 - dump+initdb+restore. Oraz być może poprawek we własnych procedurach
> > (ściślejsza kontrola typów).
> 
> Dobra. W takim razie i tak zanim nie opracujemy sposobu na to żeby upgrade 
> nie powosdował samoczynnie utraty danych i/lub wymagał dodatkowej asysty 
> błąd ten i tak musimy tolerować.

Utraty danych nie powoduje (upgrade serwera się nie wykona, jeśli
istnieją stare bazy w miejscu używanym przez aktualnie zainstalowanego
postgresa), może dojść do czasowej częściowej dysfunkcji (jeśli pomimo
niepowodzenia uaktualnienia serwera rpm zupgraduje moduły PL/* - nie
wiem, czy w 4.1 ten błąd nadal jest, 4.0.x tak miał na pewno).

Ale asysty wymaga i będzie wymagał, choćby nie wiem jakie skrypty do
tego zrobić (jest kilka okoliczności, w których polegną skrypty obecne
w RH, SuSe i Debianie... zresztą pierwszą czynnością do wykonania przed
ich uruchoniem jest backup na wypadek niepowodzenia).

Owszem, jakieś skrypty ułatwiające uaktualnienie baz można dołączyć, ale
muszą być uruchamiane świadomie. Administrator musi przekazać, jak się
dostać do baz i gdzie jest miejsce na kopię tymczasową.

> Pytanie nadal jest aktualne: jak wykonac upgrade 7.2 -> 7.3 bez 
> zostawianai na lodzie całości ?

(pg_dump wszystkich baz || pg_dumpall), rpm -U, (pg_restore baz ||
psql).

W innych dystrybucjach pozwalają jeszcze na dump po uaktualnieniu
pakietów - w %pre są kopiowane stare binarki do /usr/lib/pgsql/backup)

> Identyczne pytanei bedzie zaraz przy przejsciu na mysql 4.x wiec i tak 
> prędzej czy później musimy rozwiązać tą kalsę zagadniań.

To raczej nie ta klasa. W mysql-u mogą być jakieś niekompatybilności
dotyczące szczegółów czy niektórych formatów baz, ale dump+restore nie
jest bezwarunkowo potrzebny.

> Propozycja: stopować upgrade w sytuacji gdy nie ma gdzieś jakeigoś pliku 
> sygnalizujacego że admin wie że należy zrobić dump bazy opzred upgrade i 
> zaimportować całość po upgrade.
> Bez obecnosci tego pliku informować co należy zrobić żeby upgrade 
> przeszed i .. żeby nie utracić baz.

Zajrzyj do %pre w postgresql.spec. IMO warunek nie istnienia baz
w starym formacie w miejscu używanym przez serwer jest wystarczający
(i tak trzeba je stamtąd usunąć, żeby zrobić initdb) jest wystarczający
i nie trzeba wprowadzać dodatkowych kombinacji z plikiem.

Można jeszcze dodać sprawdzenie, czy postmaster nie jest uruchomiony
- bo wtedy po upgrade nie da się go wyłączyć przez
/etc/rc.d/init.d/postgresql.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/