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+TgmobNKFc34nj+w6iX0zWJ1=mfYWqQS91PqsJrm4VD4o1yOw@mail.gmail.com>
References: <202502131716.7mgkcnrem2hn@alvherre.pgsql> <2939991.1740089974@sss.pgh.pa.us> <CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com> <179448.1772033773@sss.pgh.pa.us> <CA+TgmoYFc1x11Y7AHxn6Jb0mvJ9-aPttmjqezj=YKnHmqVb-Wg@mail.gmail.com> <265501.1772038216@sss.pgh.pa.us> <CA+TgmobNKFc34nj+w6iX0zWJ1=mfYWqQS91PqsJrm4VD4o1yOw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 25 Feb 2026 12:33:17 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <296082.1772041154.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 25 Feb 2026 12:39:14 -0500
Message-ID: <296083.1772041154@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/296083.1772041154%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 25, 2026 at 11:50 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If you're good with pg_dumpall producing a warning and then emitting
>> the GRANT with no grantor clause, I will go make that happen.

> Well, I guess I don't really see why there should be a warning.

Because the result of the restore will not match how things were
in the source database?  True, we do not have any way to make them
match, but that doesn't mean that pg_dumpall has fulfilled all
expectations.

> Now, if you go and do as you propose here, and adjust the code so that
> the grant is dumped but a warning is produced, my fear is that someone
> upgrading from v15- to v16+ will see that warning and think that there
> is a problem with their database that needs fixing.

On the other hand, if we produce no warning and yet the restored DB
is unlike the original, that could also be cause for concern.

> Moreover, we'll emit essentially the same warning for the member case,
> where the warning does point to a problem that someone might want to
> think about correcting, and exactly the same warning against a v16+
> database where it indicates that something has actually gone wrong.

That's a fair point, but maybe it could be addressed by phrasing the
message differently for the different cases.

			regards, tom lane