Yup, that looks like the problem. Doing: postgres=# SELECT * FROM pg_auth_members postgres-# WHERE roleid NOT IN (SELECT oid FROM pg_authid);
Yields, 11 Rows, so for sure someone must have been messing around. Thanks. On Tue, Jun 16, 2015 at 11:58 AM, Jerry Sievers <gsiever...@comcast.net> wrote: > Melvin Davidson <melvin6...@gmail.com> writes: > > > Using pg_upgrade in 9.4 CentOS release 6.6 (Final) (from PostgreSQL > 9.1.15) it fails when GRANTING permits to roles. > > > > Checking pg_upgrade_dump_globals.sql, I see the point of failure is > caused by the -- Role memberships section. > > > > In there I see the following troublesome lines. > > -- Role memberships > > ... > > ... > > .... > > GRANT "supers" TO "pgpoolad" GRANTED BY "postgres"; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO ""; > > GRANT "" TO "" GRANTED BY "postgres"; > > GRANT "" TO ""; > > GRANT "" TO ""; > > > > Doing a pg_dumpall -g on the database produces the same result. > > Well then I don't presume this is a pg_upgrade issue. > > Inspect your pg_auth_members catalog for entries referring to rows > absent from pg_authid. > > Did someone manually remove rows from pg_authid? > > > I am pretty sure this is catalog corruption. > > > > Can anyone else confirm and/or suggest a recommended fix? > > > > -- > > Melvin Davidson > > > > -- > Jerry Sievers > Postgres DBA/Development Consulting > e: postgres.consult...@comcast.net > p: 312.241.7800 > -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
