On Tue, Jul 29, 2014 at 10:33:17PM -0400, Tom Lane wrote:
> 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"
> is actually not an extra restriction. You said:
>
> > o only one user can be defined in the new cluster (most likely the
> > install user)
>
> If there is only one user in the new cluster, it *is* the bootstrap
> superuser, because that user cannot be deleted.
>
> > o the oids of the two users must be the same (likely the install user
> > on the old cluster as well)
>
> 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.
OK, I had never made this logical conclusion that it had to be the
install user. Since you can't remove the install user, and the new
cluster can only have one user (the install user), and because we
preserve pg_authid.oid, the old cluster has to be the install user too.
I have developed the 9.5-only patch which simplifies these checks and
error messages; attached.
> > 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 don't think you actually can, and if you could, I frankly would not
> trust the results.
Agreed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
