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-21T21:45:18Z

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:
> On Fri, 2025-02-21 at 11:31 -0500, Tom Lane wrote:
>> ... 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.

> Both the extra sentence and the simplification feel like an improvement.
> I am fine with either.

The more I think about it the more I like just getting rid of the
test.  It'll likely break with every future change to this logic,
until somebody finally gives up on it; so why not now?

I'll make it so.  Thanks for reviewing!

			regards, tom lane