Horton

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

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Virender Singla <virender.cse@gmail.com>, pgsql-bugs@lists.postgresql.org, Aniket Jha <aniketkumarj@gmail.com>
Date: 2025-02-20T22:19:34Z
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 →

  1. Avoid race condition between "GRANT role" and "DROP ROLE".

  2. Fix pg_dumpall to cope with dangling OIDs in pg_auth_members.

  3. Ensure that pg_auth_members.grantor is always valid.

Attachments

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org> writes:
> Hmm, I think fixing the bug as Tom suggests downthread is probably a
> good idea, but I think we should in addition change pg_dumpall to avoid
> printing a GRANT line if there's no grantee.  Maybe turning one of these LEFT
> JOINs into a regular inner join is a sufficient fix for that:

After looking at this I thought it was worth a little more code to warn
about the dangling role OID, instead of just silently ignoring it.
Here's a couple of more-polished patches.

I'm unsure whether to back-patch the 0001 patch, as it does imply
more pg_shdepend entries than we have today, so it's sort of a
backdoor catalog change.  But we're mostly interested in the
transient behavior of having a lock+recheck during entry insertion,
so maybe it's fine.  0002 should be back-patched in any case.

(BTW, I was distressed to learn from the code coverage report
that we have zero test coverage of the hardly-trivial logic in
dumpRoleMembership.  I didn't try to address that here.  I did
test this new logic by dint of manually deleting from pg_authid.)

			regards, tom lane