pg_upgrade 9b4 -> 9rc1 odd behavior with -u (non-)postgres
От | Lou Picciano |
---|---|
Тема | pg_upgrade 9b4 -> 9rc1 odd behavior with -u (non-)postgres |
Дата | |
Msg-id | C4F918FB-5C91-4CE4-AE98-B4D894A5EEE5@comcast.net обсуждение исходный текст |
Ответы |
Re: pg_upgrade 9b4 -> 9rc1 odd behavior with -u
(non-)postgres
|
Список | pgsql-testers |
[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!)
В списке pgsql-testers по дате отправления: