From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@alvh.no-ip.org>,
        Virender Singla <virender.cse@gmail.com>,
        pgsql-bugs@lists.postgresql.org, Aniket Jha <aniketkumarj@gmail.com>
Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog
In-reply-to: <CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>
References: <202502131716.7mgkcnrem2hn@alvherre.pgsql> <2939991.1740089974@sss.pgh.pa.us> <CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 25 Feb 2026 08:59:04 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <179447.1772033773.1@sss.pgh.pa.us>
Date: Wed, 25 Feb 2026 10:36:13 -0500
Message-ID: <179448.1772033773@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/179448.1772033773%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> 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