@brorfred: "The following bug has been logged on the website:
Bug reference:      11090
Logged by:          Bror Jonsson
Email address:      <email_address>
PostgreSQL version: 9.2.0
Operating system:   Mac OS X
Description:        
pg_upgrade requires that the old and new database has the same install
superuser (superuser that ran initdb). If this requirement isn't fulfilled,
you'll get the following error:
"Old and new cluster install users have different values for
pg_authid.oid.\n"
(<url>
line 168)
This was very confusing to me. A suggested rephrase would be:
"Old and new cluster must be created by the same user. Try to re-init the
new database with the flag "-U %s" \n"
Where %s is the the install user in the old cluster.
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @alvherre: "<quote>
To me, the bug is that we required both superusers to be named the same
in the first place.
�lvaro Herrera                <url>
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @pierce: "<quote>
so, if its enhanced with a -U newsuperuser flag, any objects owned by 
'postgres' on the original cluster are now owned by 'newsuperuser' on 
the new cluster?
john r pierce                                      37N 122W
somewhere on the middle of the left coast
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @alvherre: "<quote>
Have you tried an UPDATE pg_authid?
�lvaro Herrera                <url>
PostgreSQL Development, 24x7 Support, Training & Services
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @tgl: "Alvaro Herrera <email_address> writes:
<quote>
Or even just ALTER USER RENAME?
			regards, tom lane
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @tgl: "David G Johnston <email_address> writes:
<quote>
Yeah, I wouldn't really expect pg_upgrade to deal with such a case.
For one thing, what if the new cluster's superuser name conflicts with
some non-superuser in the old cluster?
Having said that, I think the actual implementation restriction is not
that they have the same *name*, but that they have the same *OID*.
And the OID of the bootstrap superuser is always gonna be 10.  As long
as the new cluster's bootstrap superuser name doesn't collide with
any other usernames in the old cluster, it could in principle be
different.  The only difficulty is that pg_upgrade has but one -U
switch to specify both names ... and it's not exactly clear that it's
worth the complication to have two such switches.
I agree that it'd be better if the error message said something like
"you have to use the bootstrap superuser, which is 'foo' in this cluster".
That would be overconstraining the user of pg_upgrade, but not by much,
and it would be a lot easier to understand than the current situation.
			regards, tom lane
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @bruce: "<quote>
Basically, here are the pg_upgrade restrictions:
o  same user must exist in old and new clusters
o  only one user can be defined in the new cluster (most likely the
install user)
o  the oids of the two users must be the same (likely the install user
on the old cluster as well)
The error message generated:
	"Old and new cluster install users have different values for
	pg_authid.oid.\n"
basically is failing on the last check.  Odds are the user specified by
-U existed in both the old and new clusters, and was the sole/install
user in the new cluster.  What failed was that the old user was not the
install user, so didn't have the install oid (10) in the old cluster.
I am not sure we can improve that error message.  I don't think we can
assume anything more than an oid mismatch.  The oids might not match
because of the case above, or the new cluster might have created a new
user and then dropped the install user, and in that case the new user
oid would be the wrong one.
The basic logic is outlined in this C comment:
     * We only allow the install user in the new cluster because other defined
     * users might match users defined in the old cluster and generate an
     * error during pg_dump restore.
What I think you actually can do is to run pg_upgrade with a user that
is not the install user in either cluster, as long as the oids match.  I
am afraid any more specific message could technically be wrong in some
rare cases.
  Bruce Momjian  <email_address>        <url>
  EnterpriseDB                             <url>
  + Everyone has their own god. +
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @tgl: "Bruce Momjian <email_address> writes:
<quote>
I think you missed my point.  I'm suggesting actually restricting what
pg_upgrade will accept, so that the error conditions become simpler to
understand.
Furthermore, if your description of the restrictions is accurate, then
restricting to "the user must be the bootstrap superuser in both clusters"
If there is only one user in the new cluster, it *is* the bootstrap
superuser, because that user cannot be deleted.
If the OIDs are the same, then the old-cluster user is also the bootstrap
superuser, because the bootstrap superuser's hard-wired OID is 10.  QED.
So I think you should get rid of the existing error check and simplify it
to "user must be bootstrap superuser (ie, OID 10) in both clusters".
The existing approach adds only confusion, not flexibility.
I don't think you actually can, and if you could, I frankly would not
trust the results.
			regards, tom lane
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @bruce: "<quote>
Patch applied, with doc addition.
  Bruce Momjian  <email_address>        <url>
  EnterpriseDB                             <url>
  + Everyone has their own god. +
Sent via pgsql-bugs mailing list (<email_address>)
To make changes to your subscription:
<url>"
{'source': 'USENET', 'other_information': '{"reply_count": 8, "forum_name": "mailing.database.pgsql-bugs.20141226.mbox"}', 'file': 'data/output/usenet-mailing.database.parquet'}