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-21T16:31:09Z

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:
> Thanks for the explanation.  That might be worth a comment.

The adjacent comment already says

	/*
	 * Advance command counter so we can see new record; else tests in
	 * AddRoleMems may fail.
	 */

so I didn't see anything to add there.  Maybe "We can skip this in
cases where we will not call AddRoleMems"?  Or maybe the better answer
is to conclude that the whole idea of not calling
CommandCounterIncrement unconditionally is too fragile and not worth
expending brain cells on, and just rip out the if-test.

			regards, tom lane