Re: LOST REFERENTIAL INTEGRITY
От | Marco Colombo |
---|---|
Тема | Re: LOST REFERENTIAL INTEGRITY |
Дата | |
Msg-id | Pine.LNX.4.61.0410051127550.14637@Megathlon.ESI обсуждение исходный текст |
Ответ на | Re: LOST REFERENTIAL INTEGRITY (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Mon, 4 Oct 2004, Tom Lane wrote: > "Jimmie H. Apsey" <japsey@futuredental.com> writes: >>> I'd recommend an upgrade to 7.4.5 at your earliest convenience. >>> >> I have kept up-to-date our Red Hat kernels as you can probably see from >> the Linux 2.4.9-e.49smp kernel. Am I required to maintain my own >> version of Postgres alongside and compiled into Red Hat's latest and >> greatest kernel? If that's true, WHEW! > > Unfortunately I don't get to dictate Red Hat's backwards-compatibility > policies :-( ... and their policy for AS 2.1 is that it's gonna be > Postgres 7.1 till it dies. This means that anything that's > fundamentally unfixable without an initdb is going to remain broken. AFAIK, the policy is to keep _compatible_ version, which is a sound policy. RH users sould be able to perform upgrades w/o fear of losing anything. I can't speak for the postgresql RPM, but I know their policy is to backport fixes (if possible). Unluckily, sometimes a pg_dumpall & restore just won't do. You need to manually edit your dump for the next version of postgres to be able grok it. Nothing hard, usually, just silly stuff, but anyway that rules out an automatic dump&restore at rpm -U time. Of course, no one prevents you from compiling your own version of postgres and running it on a separate dataspace. .TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
В списке pgsql-general по дате отправления: