Hi, Martin, Martin Pitt wrote:
> Right, thanks for that hint. Humm, how is that solved in URL > standards? AFAIK IPv6 adresses in URLs have to be enclosed in > brackets, right? E. g. [1234::1:1]:5432. AFAIR yes. SSH alternatively allows to split host and port with a / for the -L and -R options. A technically simple solution would be to define that the last : always divides host and port, and for the default port, we can omit the port number, but not the : when using IPv6, so we have to give 1234::1:1: for default port. > Right, I cannot drop 7.4 support for Etch, since it is necessary for a > clean Sarge upgrade. But I don't want to maintain more than two major > versions, I already have more than enough to do with them. I perfectly understand. So it is possible that you also drop 8.1 and upgrade to 8.2 before Etch is released. > Yes, by all means. The direct upgrade with pg_upgradecluster should > work fine. Just be sure to use version 34, it fixes the last missing > obsolete configuration parameters of 8.1. I already had a look at pg_upgradecluster, and I think it's a great help for most databases out in the wild, and we already migrated our sql_ledger database this way. But I'm afraid that it won't work for all of our databases, as we heavily use PostGIS (both self-compiled and the debian packages from Alex Bodnaru) which has different internal definitions depending on the PostgreSQL version. We also have used the old PGDATADIR environment variable mechanism to control disk storage, and will have to use TABLESPACES now, so an auto migration is likely to fail. Two other points are that we'll reorganize our databases using the multi-cluster capabilities by separating independent databases into independent clusters (this eases migration to different machines later). And for some large, read-only ones (GIS map data, about 50 Gig each) it is faster to recreate them from our initial data. Thanks, Markus
signature.asc
Description: OpenPGP digital signature
