Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table

Hi,

You can see the attached v5 patch. Basically, v5 solves the problem by
adding dangling-role filtering directly inside buildACLCommands(). A
role name that consists entirely of digits is potentially a dangling
OID reference and it resolves by querying pg_authid once at the start
of the dump for any legitimate all-digit role names. The sorted list
is passed as new digitRoles/nDigitRoles parameters to
buildACLCommands(), which skips any REVOKE or GRANT item whose grantee
or grantor matches a dangling reference.

I defined a static called is_dangling_role_ref in dumputils.c and
introduced two new parameters to buildACLCommands to eliminate the
dangling grantee or grantor objects.

When it comes to patching the HEAD I'm going to create and submit
another small patch.

Regards,
Demir.

Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>, 23 Haz 2026 Sal, 10:32
tarihinde şunu yazdı:
>
> > I have a more pressing concern: has any performance testing been
> > done on this? It looks like it'd be absolutely catastrophic for
> > pg_dump performance on databases with lots of objects.
> >
> > The implementation direction I'd been vaguely imagining was for
> > pg_dump's buildACLCommands() to drop any AclItems that contain
> > dangling role references (ie, numeric OIDs where a role name
> > should be). If the given role name contains any non-digit
> > characters then it's certainly not dangling, so most of the time
> > this'd be a very cheap check. However, if somebody does
> >
> > CREATE USER "007";
> > GRANT ALL ON TABLE mi6_operations TO "007";
> >
> > we mustn't get fooled by that. The backend is doing us no favors by
> > not making numeric OIDs visibly different from all-digit role names
> > in AclItems. In HEAD I'd advocate fixing that on the server side
> > (as attached), but we can't assume that a back-branch server has such
> > a fix. What we could do with an old server is issue a query (once per
> > pg_dump run) to collect all the valid all-digit role names, which
> > should surely be a short list in most databases, and then filter
> > against that within buildACLCommands().
>
> I see the approach and it's a valid concern. I can create a v5 to
> comply with your suggestion and can create a new patch to be applied
> to the current HEAD.
>
> After preparing the v5 I'm going to create a new CF to be patched to
> HEAD since this fix will be backpatched.
>
> Regards,
> Demir.