Re: Major Version Upgrade failure due to orphan roles entries in catalog

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Virender Singla <virender(dot)cse(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org, Aniket Jha <aniketkumarj(at)gmail(dot)com>
Subject: Re: Major Version Upgrade failure due to orphan roles entries in catalog
Date: 2026-02-25 16:50:16
Message-ID: 265501.1772038216@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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 don't entirely agree that it's "business as usual": somebody screwed
up to get the database into that state. I'm not here to apportion
blame for that between the user and the database, but I do think it's
appropriate for pg_dumpall to complain that it's facing invalid data.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Álvaro Herrera 2026-02-25 16:57:59 Re: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change
Previous Message Vishal Prasanna 2026-02-25 16:32:54 RE: [BUG] Assert failure in ReorderBufferReturnTXN during logical decoding due to leaked specinsert change