Mike M. Volokhov [Mon, Jan 12, 2004 at 06:06:48PM +0200]:
> This will cause to long stand idle
> period until incorectly restored DB will be repaired. This is
> inacceptable for many companies.

I think we can ignore such point. If you need to have database server
running 24/7, you'll need something more, than a single server with a single
PostgreSQL installation -- so, if you're looking for ways to deliver high
availability, you're looking in wrong place.

If you want to keep your current installation running, you can still compile
and install new PostgreSQL in some other place, check, if it accepts the
dump, and so.

If you're looking for PgSQL (almost)HA solutions, check
http://gborg.postgresql.org

> Another problem is a possible data
> loss or damage. In this case DB will be operationing incorrectly and
> this may cause to another (even non technical) problems.

I will repeat my question. Why do you somehow belive, that doing
dump/restore by hand will save you from data loss, in case there are errors
in dump, and DB backend will silently ignore them? Wisely crafted automatic
script can do its job very well, without any risk of loosing the data.

> Moreover, if DB
> will not be restored automatically (but this may be reality), that
> script just useless.

I think it's better to have such automatic script, which won't work in 10%
of cases, than to not to have such script at all.

> Generally say, good solution is create new (hardware dedicated) database
> server, install new DBS on it, and then copy all data from old one to
> another. After that new DBS should be tested withing some planned
> period. And when testing will positively done, servers should be
> substituted.

... of course, if your DB dump takes low amout of time and there are no
writes to the DB in this time, that's okay. What will you suggest for
databases, which dump the data for about 2 hours, while the database is
constantly changed and updated? :)

> Another solution (as I've already mentioned) is use pkgviews. If DB
> server had a resources enough, it would be theoretically possible.

That's not a bad idea.

> Relatively to this PostgreSQL package, IMHO it is better to mention that
> incompatibles in the MESSAGE file thus DBA will able to handle them.

As MESSAGE is displayed _after_ installation, I think it's quite late for
this in this case. 

-- 
Michal Pasternak :: http://pasternak.w.lub.pl :: http://winsrc.sf.net
::don't use MySQL::details on http://sql-info.de/mysql/gotchas.html::