Re: Major Version Upgrade failure due to orphan roles entries in catalog - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Major Version Upgrade failure due to orphan roles entries in catalog
Date
Msg-id 1106526.1772229127@sss.pgh.pa.us
Whole thread Raw
In response to Re: Major Version Upgrade failure due to orphan roles entries in catalog  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Feb 27, 2026 at 4:28 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Sigh, this time with it really attached.

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

> Regarding this point:
>> I'm inclined to
>> think that is an overreaction to the possible unreliability of the
>> data (and from your comment upthread you might agree).

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

            regards, tom lane



pgsql-bugs by date:

Previous
From: Robert Haas
Date:
Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog
Next
From: PG Bug reporting form
Date:
Subject: BUG #19421: PostgreSQL MERGE Crash: heap_compute_data_size() at heaptuple.c:236