Thread: pg_dumpall -r -c try to drop user postgres

pg_dumpall -r -c try to drop user postgres

From
Pavel Stehule
Date:
Hi I am not sure if user postgres should be removed, so it is probably bug pg_dumpall -r -c | grep postgres DROP ROLE postgres; CREATE ROLE postgres; Regards Pavel

Re: pg_dumpall -r -c try to drop user postgres

From
Michael Paquier
Date:
On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I am not sure if user postgres should be removed, so it is probably bug
>
> pg_dumpall -r -c | grep postgres
>
> DROP ROLE postgres;
> CREATE ROLE postgres;

You are looking for this bit of code:
                /*
                 * If asked to --clean, do that first.  We can avoid detailed
                 * dependency analysis because databases never depend
on each other,
                 * and tablespaces never depend on each other.  Roles could have
                 * grants to each other, but DROP ROLE will clean
those up silently.
                 */
                if (output_clean)
                {
                        if (!globals_only && !roles_only && !tablespaces_only)
                                dropDBs(conn);

                        if (!roles_only && !no_tablespaces)
                                dropTablespaces(conn);

                        if (!tablespaces_only)
                                dropRoles(conn);
                }
Could you clarify what you think is wrong here?
-- 
Michael


Re: pg_dumpall -r -c try to drop user postgres

From
Pavel Stehule
Date:


2017-12-03 23:48 GMT+01:00 Michael Paquier <michael.paquier@gmail.com>:
On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I am not sure if user postgres should be removed, so it is probably bug
>
> pg_dumpall -r -c | grep postgres
>
> DROP ROLE postgres;
> CREATE ROLE postgres;

You are looking for this bit of code:
                /*
                 * If asked to --clean, do that first.  We can avoid detailed
                 * dependency analysis because databases never depend
on each other,
                 * and tablespaces never depend on each other.  Roles could have
                 * grants to each other, but DROP ROLE will clean
those up silently.
                 */
                if (output_clean)
                {
                        if (!globals_only && !roles_only && !tablespaces_only)
                                dropDBs(conn);

                        if (!roles_only && !no_tablespaces)
                                dropTablespaces(conn);

                        if (!tablespaces_only)
                                dropRoles(conn);
                }
Could you clarify what you think is wrong here?

I am not sure, if issue is in this code. But I am sure, so DROP ROLE postgres is just nonsense

This command should to fail every time, and then should not be generated.

Regards

Pavel

 
--
Michael

Re: pg_dumpall -r -c try to drop user postgres

From
Jeff Janes
Date:
On Tue, Dec 5, 2017 at 9:03 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> I am not sure if user postgres should be removed, so it is probably bug
>
> pg_dumpall -r -c | grep postgres
>
> DROP ROLE postgres;
> CREATE ROLE postgres;

 
I am not sure, if issue is in this code. But I am sure, so DROP ROLE postgres is just nonsense

This command should to fail every time, and then should not be generated.

I don't see why it should fail every time.

Not all databases clusters were created with their initdb superuser being 'postgres'.

Cheers,

Jeff