=?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip.rembialkowski@xxxxxxxxx> writes: > On Wed, Apr 25, 2012 at 8:56 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> Hmm. A look at the code in pg_dumpall suggests that the problem is >> unmatched entries in pg_auth_members, ie this query: >> >> SELECT ur.rolname AS roleid >> FROM pg_auth_members a LEFT JOIN pg_authid ur on ur.oid = a.roleid >> >> is returning some null results. > Yes that is the case: Ah-ha. How about the member and grantor OIDs in those rows --- do they correspond to still-existing roles? (I believe "10" would be the bootstrap superuser, so that should certainly still exist, but those other numbers are for user-made roles.) > Could it be (theoretically) caused by human-made insertions into > pg_auth_members? Well, perhaps ... are you in the habit of hacking that catalog directly? Aside from the possibility of inserting a just-plain-wrong OID, there's the possibility of inserting a valid row but forgetting to add a pg_shdepend entry that would protect the row against the underlying role being dropped. > Maybe you remember some bug which could have caused this in the past? Doesn't ring a bell offhand. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
