Hi, I had the same problem. The situation I (and probably you) had was: - old 8.2 cluster with default encoding: [EMAIL PROTECTED] + encoding of databases "template0", "template1" and "postgres": [EMAIL PROTECTED] + encoding of database "test": UTF-8 - current system locale: de_DE.UTF-8
My custom solution was to: - hardcode UTF-8 as the 8.3 cluster default encoding, which ignores the detected encoding of the old 8.2 cluster - don't upgrade template0, template1 and postgres databases Attached is a patch for pg_upgradecluster, but be aware that this is a custom hack that works for me, not a proper solution. Regards, Bastian
--- /usr/bin/pg_upgradecluster.orig 2008-02-07 22:14:14.000000000 +0100
+++ /usr/bin/pg_upgradecluster 2008-02-07 22:14:21.000000000 +0100
@@ -227,6 +227,9 @@
my ($lc_ctype, $lc_collate) = get_cluster_locales $version, $cluster;
error 'could not get cluster locale' unless $lc_ctype;
error 'could not get cluster collating locale' unless $lc_collate;
+$encoding = "UTF-8";
+$lc_ctype = "de_DE.UTF-8";
+$lc_collate = "de_DE.UTF-8";
if (cluster_exists $newversion, $cluster) {
error "target cluster $newversion/$cluster already exists";
@@ -372,6 +375,8 @@
# Upgrade databases
for my $db (keys %databases) {
next if $db eq 'template0';
+ next if $db eq 'template1';
+ next if $db eq 'postgres';
if ($db eq 'postgres' && $newversion ge '8.1') {
(system 'dropdb', '--cluster', "$newversion/$cluster", '-q', 'postgres');
signature.asc
Description: This is a digitally signed message part.
