Morten Nilsen <[EMAIL PROTECTED]> wrote:
> Christian H. Toldnes wrote:
>> We need to figure out a way of doing that transition though, since
>> 3.0 users will be automatically upgraded to 3.1 when it's out. 3.1 is
>> actually just 3.0 with changes that are taking place during 3.0, and
>> some changes to the ISOs etc.
>
> if the manual interaction is as easy as I think it is, doing a simple
> dump in preun, and import in post should do the trick..
>
> as a bonus, if the install barfs, it would leave a dump in some
> predetermined location for easy recovery..

Some thoughts on that:
I would not recommend an automated way to perform a major PostgreSQL
update - whereas a somewhat assisted way would be fine.

For the 7.4 / 8.0 upgrade there were some improvements to the pg_dump
utility so I really recommend to do the dump with the 8.0 pg_dump remotely
to the existing and running 7.4. It eases the recovery process a lot after
the upgrade to 8.0. I don't know if we get such a situation again in future
updates.

Before you can restore the dump, you have to initiate a new database
cluster. AFAIR you have to tell which locale to use at this step.

Nevertheless it is possible that PostgreSQL will bark during the import of
the dump on minor problems so you do good in testing the procedure on a
spare machine before. Most of the problems are simple to work around with
little modifications to the dump-script.

Next thing to think about is that you should really read the release notes
of the new release and double check that you're not affected by on of the
few changes in the behaviour of SQL or PL/pgSQL commands and you have to
ensure that your stored procedures and your business application built on
top will work with the new version as well.

Please, do not misunderstand me - an update to postgresql isn't such a big
thing - most likely you will not encounter any problems at all. But you
should do it a controlled way and - for safety reasons - in an maintenance
window. You might somehow compare a major postgresql upgrade to a major PHP
upgrade.

<szenario_to_prevent>
Imagine you have installed swupcron, and it tries to automatically upgrade
postgresql somehow with a dump/restore script. On the next busy monday
morning you first start to debug your business logic application because it
seems to misbehave - than someone reports he cannot connect to his virtual
mailbox and later your customers claiming your dynamical webpage is throwing
lots of errors. Than you really need nerves of steel to quickly figure out
the problem and repair the database server ;)
</szenario_to_prevent>

Regards
Tobias

_______________________________________________
tsl-discuss mailing list
[email protected]
http://lists.trustix.org/mailman/listinfo/tsl-discuss

Reply via email to