Russell Smith wrote:
>>>>> CREATE ROLE test_role
>>>>> NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
>>>>>
>>>>> CREATE ROLE invalid_grantor
>>>>> SUPERUSER INHERIT NOCREATEDB NOCREATEROLE;
>>>>>
>>>>> SET ROLE invalid_grantor;
>>>>> GRANT "postgres" TO "test_role";
>>>>> SET ROLE postgres;
>>>>>
>>>>> select * from pg_roles;
>>>>>
>>>>> select pg_auth_members.*, ur.rolname, gr.rolname from
>>>>> pg_auth_members LEFT JOIN pg_roles ur ON roleid = oid
>>>>> LEFT JOIN pg_roles gr ON gr.oid = grantor;
>>>>>
>>>>> DROP ROLE invalid_grantor;
>>>>>
>>>>> select pg_auth_members.*, ur.rolname, gr.rolname from
>>>>> pg_auth_members LEFT JOIN pg_roles ur ON roleid = oid
>>>>> LEFT JOIN pg_roles gr ON gr.oid = grantor;
>>>>>
>>>>> DROP ROLE test_role;
>>>>>
>>> So does this make a todo item?
>>>
>>> But this still leaves the concerns about you can currently get the
>>> database into an invalid state that can't be dumped and restored.
>>>
>>
>> Correct, which makes it a bug (==> needs fixed) rather than a todo item.
>>
>> We now have a problem because there may already be databases that are
>> undumpable. We might need to provide a workaround for people with such
>> a database.
>>
[snip]
As I am not a frequent reporter of bugs, what happens now? It's been a
week since I wrote my last message and I'm unsure of whether anything
has, or is going to happen about this bug report. Alvaro has said it's
a "bug", so it needs fixing. But that has not translated into somebody
saying they will look at it. I've also had no comments on the possible
patch I attached in my last email.
I understand people are busy, but as a follower of pg development, from
this experience I can see who some new people get the feeling of not
being looked after. Even if something is happening, there is little
flow of information.
I would greatly appreciate an update, even though this is not a server
crash, it does allow creation of dumps that cannot be restored. They
can be alter to be restored, but I didn't think that was the point.
Regards
Russell Smith