public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Virender Singla <[email protected]>
Cc: [email protected]
Cc: Aniket Jha <[email protected]>
Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog
Date: Wed, 25 Feb 2026 10:36:13 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>

Robert Haas <[email protected]> writes:
> I recently learned of a case where this commit caused role grants to
> be erroneously emitted from the output of pg_dumpall. In the case in
> question, a v16 pg_dumpall was used against an older server.  Hence,
> dump_grantors was false, and any generated GRANT commands would not
> have included in the grantor anyway. Nevertheless, this logic caused
> those grants to be skipped altogether:
> ...
> If you do this on v15 and then run v15's pg_dumpall, it will dump
> "GRANT foo to bar", with no GRANTOR clause due to the PQgetisnull()
> gating that logic. v16's pg_dumpall will dump nothing and emit a
> warning instead. Arguably, pre-v16 pg_dumpall shouldn't EVER be
> dumping the grantor since the grantorid could be an old role OID that
> has been recycled for a new role, and relying on that for anything
> security-critical seems like a mistake, but that behavior is also
> longstanding. But omitting the grant altogether seems like an
> overreaction. I understand that we need to do that when the *member*
> is invalid, of course; in that case, there's no alternative. But
> that's not the case for the grantor.

Hmm.  As per the commit message,

    Pre-v16 branches already coped with dangling grantor OIDs by simply
    omitting the GRANTED BY clause.  I left that behavior as-is, although
    it's somewhat inconsistent with the behavior of later branches.

So what you're saying is that I should have made the later branches
do that also.  I guess it's arguably better than dropping the grant
altogether ... but the end result will be that the grant is now
granted by the superuser running the restore, which doesn't seem
very good either.

			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]
  Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog
  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