Re: BUG #11090: Unclear error message in pg_upgrade - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #11090: Unclear error message in pg_upgrade
Date
Msg-id 20140730145803.GG2791@momjian.us
Whole thread Raw
In response to Re: BUG #11090: Unclear error message in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #11090: Unclear error message in pg_upgrade
List pgsql-bugs
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. +

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [ADMIN] Can postgres run autovacuum tasks when autovacuum is disabled?
Next
From: Tom Lane
Date:
Subject: Re: [ADMIN] Can postgres run autovacuum tasks when autovacuum is disabled?