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 11:30:39 -0500
Message-ID: <CA+TgmoYFc1x11Y7AHxn6Jb0mvJ9-aPttmjqezj=YKnHmqVb-Wg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CA+TgmoauoiW4ydDhdrseg+DD4Kwha=+TSZp18BrJeHKx3o1Fdw@mail.gmail.com>
	<[email protected]>

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

It does not, but it seems better than having a v16 pg_dumpall and v15
pg_dumpall produce non-logically-equivalent dumps of the same
database. My instinct is that this test:

                                if (PQgetisnull(res, i, i_grantor))

Should instead look like this:

                                if (PQgetisnull(res, i, i_grantor) &&
dump_grantors)

In v16+, if the grantor is not valid, that's unexpected and something
has gone wrong, perhaps due to insufficient locking, or maybe due to
catalog corruption. The warning is a fair response to a
seemingly-corrupted catalog state. But in v15-, this is just business
as usual; there's no particular expectation that the grantor must be a
valid role OID, and IMHO the best thing to do is give the same result
that a pre-v16 pg_dumpall would have produced.

I'm not actually completely confident that I have a fully correct
analysis of this problem. But I do think that it's hard to argue that
dumping the same database with different pg_dumpall versions should
produce logically different results.

-- 
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+TgmoYFc1x11Y7AHxn6Jb0mvJ9-aPttmjqezj=YKnHmqVb-Wg@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