public inbox for [email protected]
help / color / mirror / Atom feedFrom: 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: Mon, 2 Mar 2026 09:19:29 -0500
Message-ID: <CA+TgmoZmWg9FfHBLxw7vCJ7pkdWJtW6AMCUvoARTVYqcmeAW=w@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]>
<CA+TgmoYJ8Y1G1r9U7pRwnyw=8dmM0xygLguE+bdihkN8GwPuCQ@mail.gmail.com>
<[email protected]>
<CA+TgmobZRL02-R7k_i3ENYz8CmqCPUZv6cHY51BejqPy7OhFJw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+TgmobMUVTj=5csi-vT=w731H5PBj+0SpCS_AndZEv_eum-jA@mail.gmail.com>
<[email protected]>
On Fri, Feb 27, 2026 at 4:52 PM Tom Lane <[email protected]> wrote:
> > I suggest that having both a variable called dump_grantor and one
> > called dump_grantors is a little bit subtle, but other than that this
> > looks good on a quick read-through.
>
> Fair ... do you have a suggestion for less confusing names?
> I considered naming the new variable "dump_this_grantor", but thought
> it was longer without being more helpful ... but maybe you disagree.
Personally, I'd find the extra verbosity helpful, but I don't care
that much if you see it otherwise.
> > I think this is my code, so I certainly believed I had the right idea
> > at the time, but we could revisit that. One thing to keep in mind is
> > that in v15-, regardless of the notional grantor, in effect all grants
> > are independent of the existence of any other user. In v16+, they form
> > a tree structure, with grants depending on their grantors. So, when
> > upgrading from v15- to v16+, we have to end up with a valid tree
> > structure, but there's absolutely no reason to think that we already
> > have one.
>
> Yeah, that is certainly a hazard we'd have to worry about. As I said,
> I'm content to leave it as-is for now.
Yeah, sure. I was just mentioning it in case you were planning to
pursue that in a separate thread.
--
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+TgmoZmWg9FfHBLxw7vCJ7pkdWJtW6AMCUvoARTVYqcmeAW=w@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