| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com> |
| Cc: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: empty role names in pg_dumpall output |
| Date: | 2012-04-27 17:23:32 |
| Message-ID: | 23200.1335547412@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip(dot)rembialkowski(at)gmail(dot)com> writes:
> On Wed, Apr 25, 2012 at 8:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | savio rodriges | 2012-04-27 17:45:12 | |
| Previous Message | leaf_yxj | 2012-04-27 17:22:26 | Re: how to set up automatically startup database when the server boot or reboot. |