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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Laurenz Albe <laurenz.albe@cybertec.at>

Cc: Álvaro Herrera <alvherre@alvh.no-ip.org>, Virender Singla <virender.cse@gmail.com>, pgsql-bugs@lists.postgresql.org, Aniket Jha <aniketkumarj@gmail.com>

Date: 2025-02-21T14:41:43Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Avoid race condition between "GRANT role" and "DROP ROLE".
- 98fc31d64991 18.0 landed
Fix pg_dumpall to cope with dangling OIDs in pg_auth_members.
- d850a6600cec 16.9 landed
- ce1475acd5e2 14.18 landed
- 6df3be415cdb 15.13 landed
- 29d75b25b567 18.0 landed
- 16eff4261f46 17.5 landed
- 5302ff95cadd 13.21 landed
Ensure that pg_auth_members.grantor is always valid.
- 6566133c5f52 16.0 cited

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> I have one question about the first patch:

>> -	if (addroleto || adminmembers || rolemembers)
>> +	if (addroleto || adminmembers || rolemembers || !superuser())
>> 		CommandCounterIncrement();

> That change seems unrelated to the problem at hand, and I don't see it
> mentioned in the commit message.  Is that an oversight you fixed on the
> fly?

Well, kinda, because the patch doesn't work without it.  The
problematic case is where none of those 3 flags are set and also
!superuser, so that we decide we need the default grant implemented a
few lines further down.  That grant now has an explicit reference to
the new roleid, and if we haven't CommandCounterIncrement'ed, the
pg_shdepend code will error out because it doesn't see the catalog
entry for roleid.

			regards, tom lane