MIME-Version: 1.0
References: <19483-80de42dc4e62cfd6@postgresql.org>
 <CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg@mail.gmail.com>
 <104812.1780847519@sss.pgh.pa.us>
 <CAB5wL7bo-7okBCJ24fdVn4UhnuPLPG22eQjaLJZ9GJtv0FEWMg@mail.gmail.com>
 <CAB5wL7bunPCi93Bwi7zN_1gFAZhKLwS=Fsub91SW417xujGtNA@mail.gmail.com>
 <CAB5wL7aKGFFEF1SM54GxvaQPH=7Bs=HuUCqi7F4Ve025+Z950A@mail.gmail.com>
 <CAB5wL7aK6UaukMSegzEG68y0VrKOg7wFnPNRaDaHreBf2iVWag@mail.gmail.com>
 <d305af372949be0c2c4155168ca7ba97e160bc52.camel@cybertec.at>
 <5184088806e70ed5db7e83bd6540a016b3802c1d.camel@cybertec.at>
 <CAB5wL7ZuFwu2Sd-xmn-w5-BbrKk_Mu_1ubYow_qaqFGhJOiMXw@mail.gmail.com>
 <CAB5wL7ai8AiaFV6B8J=w6vK1Q6Z9Hmp_y3PFL2Zzpx6Y8xPZ2A@mail.gmail.com>
 <0d7531c192859057c6aad54c89a8d453376bd00c.camel@cybertec.at>
 <592839.1782153054@sss.pgh.pa.us>
In-Reply-To: <592839.1782153054@sss.pgh.pa.us>
From: =?UTF-8?Q?H=C3=BCseyin_Demir?= <huseyin.d3r@gmail.com>
Date: Tue, 23 Jun 2026 10:32:34 +0200
Message-ID: 
 <CAB5wL7btFp-XRBfv_J-YperoK+e0uYje3ZYsfTzCuHcUWWrvbw@mail.gmail.com>
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv
 catalog table
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
 Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAB5wL7btFp-XRBfv_J-YperoK%2Be0uYje3ZYsfTzCuHcUWWrvbw%40mail.gmail.com>
Precedence: bulk

> 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.