public inbox for [email protected]  

help / color / mirror / Atom feed
From: Robert Haas <[email protected]>
To: Tom Lane <[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 13:02:46 -0500
Message-ID: <CA+TgmoYJ8Y1G1r9U7pRwnyw=8dmM0xygLguE+bdihkN8GwPuCQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>
	<[email protected]>
	<CA+TgmoYFc1x11Y7AHxn6Jb0mvJ9-aPttmjqezj=YKnHmqVb-Wg@mail.gmail.com>
	<[email protected]>
	<CA+TgmobNKFc34nj+w6iX0zWJ1=mfYWqQS91PqsJrm4VD4o1yOw@mail.gmail.com>
	<[email protected]>

On Wed, Feb 25, 2026 at 12:39 PM Tom Lane <[email protected]> wrote:
> 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.

That's a fair point. On the flip side, the grantor in v15- is
basically a comment. From v16, it behaves in the way we'd normally
expect: a role grant depends on the grantor in the same way that a
table grant depends on the grantor in the table ACL, just with a
different catalog representation. In v15-, it has no functional
impact.

> > 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.

I like that idea. I think the biggest danger here for users is
actually that we have to convert the pre-v16 "it's a comment" catalog
state into a v16+ "it's a real thing that works like the rest of the
authorization system" catalog state, and there's no way to do that
perfectly because we're starting from a busted catalog representation.
It seems reasonable to somehow let people know that whatever we're
doing is an approximation. If we can make the "invalid grantor from
pre-v16" sound like "don't panic but we have to patch some stuff up so
you can upgrade" and the "invalid grantor for v16+" and "invalid
member" cases sound like "uh oh, it seems like something got
corrupted" then I'm entirely happy with that state of affairs
(assuming we also resume dumping the GRANT, of course).

Thanks,

-- 
Robert Haas
EDB: http://www.enterprisedb.com






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: <CA+TgmoYJ8Y1G1r9U7pRwnyw=8dmM0xygLguE+bdihkN8GwPuCQ@mail.gmail.com>

* 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