Postgres Pro
Downloads
Home   >   mailing lists

Thread: pg_upgrade 9b4 -> 9rc1 odd behavior with -u (non-)postgres

pg_upgrade 9b4 -> 9rc1 odd behavior with -u (non-)postgres

From
Lou Picciano
Date:
[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, SUPERUSER LOGIN CREATEROLE CREATEDB, and has been given 'trust' access.  Logging turned on in config.  Otherwise, cluster has 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 subsequent run 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 Cluster B 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!)

Re: pg_upgrade 9b4 -> 9rc1 odd behavior with -u (non-)postgres

From
Bruce Momjian
Date:
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. +