Lou Picciano wrote:
> [TEST REPORT]
> [Release]: 9.0 RC1
> [Test Type]: pg_upgrade: 9.0-beta4 (Cluster 'A') -> 9.0-RC1 (Cluster 'B') user 'non'-postgres.
> [Test]: pg_upgrade (...options...) -u master
> [Platform]: Solaris 10 - Sun E450 Quad
> [Parameters]: Our administrator role is 'master' in both clusters. User 'master' has been created in Cluster B,
SUPERUSERLOGIN CREATEROLE CREATEDB, and has been given 'trust' access. Logging turned on in config. Otherwise,
clusterhas been left in 'initdb' condition.
> [Failure]: YES.
> [Results]: Script connect to Database 'A' and dumps catalog, apparently without error.
> Connects to Database 'B', crashes on attempt to create user 'postgres' - which, of course, already exists. Any
subsequentrun crashes on attempt to create 'first' user in cluster, already created in prior run.
> [Comments]: Collation and encoding significant? # initdb -D /cloud/rc1 -E UTF8 --locale=en_US.UTF-8 (to be sure
ClusterB encoding and 'lc_collate' matches that of Cluster A)
> DEBUG: autovacuum: processing database "postgres"
> WARNING: some databases have not been vacuumed in over 2 billion transactions
> DETAIL: You might have already suffered transaction-wraparound data loss.
>
> (really looking forward to being able to use pg_upgrade; looks like it will save a lot of work!)
Did you run initdb with --username?
initdb --username=master
I am thinking you didn't because it says the 'postgres' user already
exists in the new cluster. Also, please show me the exact error
message.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
