public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Euler Taveira <[email protected]>
Cc: Álvaro Rodríguez <[email protected]>
Cc: [email protected]
Cc: Javier Maellas <[email protected]>
Cc: Diego Revenga <[email protected]>
Cc: Nathan Bossart <[email protected]>
Subject: Re: pg_dumpall can't be restored with different bootstrap superuser
Date: Tue, 05 May 2026 15:10:47 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+C_kKWHMP4c56jx1BPvP1jmjp2pmBu0Cw07fPVECUmkJSnT4w@mail.gmail.com>
	<[email protected]>

"Euler Taveira" <[email protected]> writes:
> On Tue, May 5, 2026, at 7:51 AM, Álvaro Rodríguez wrote:
>> We have hit an issue with pg_dumpall --roles-only where the role grants 
>> to other roles can't be reapplied in a clean database, if the bootstrap 
>> superuser does not have the same name in both databases.

> This is not a bug. There is no way that pg_dumpall knows that the bootstrap
> user you want is another one.

I don't think that pg_dumpall is to be blamed; this is the backend's
fault.  I thought we had made this better in dd1398f13, but it still
seems rather bogus:

regression=# create user super with superuser;
CREATE ROLE
regression=# create user a;
CREATE ROLE
regression=# create user b;
CREATE ROLE
regression=# grant a to b granted by super;
ERROR:  permission denied to grant privileges as role "super"
DETAIL:  The grantor must have the ADMIN option on role "a".

Surely a superuser should be considered to have admin options
on everything.  Even more bogus, compare these results:

regression=# \c - super
You are now connected to database "regression" as user "super".
regression=# grant a to b granted by super;
ERROR:  permission denied to grant privileges as role "super"
DETAIL:  The grantor must have the ADMIN option on role "a".

regression=# grant a to b;
GRANT ROLE

Anyone would think that "GRANTED BY current_user" has the
same effect as omitting the clause, but here it doesn't.

So it seems to me that we're missing a superuserness check
somewhere in this, but I'm not entirely sure which bit of
code to blame.

I agree that the answer for existing branches is probably
going to be "so don't do that", but maybe we can improve
this in v19 or later.

			regards, tom lane

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pg_dumpall can't be restored with different bootstrap superuser
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox