Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Hüseyin Demir <huseyin.d3r@gmail.com>
From: Hüseyin Demir <huseyin.d3r@gmail.com>
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
Date: 2026-06-23T08:32:34Z
Lists: pgsql-bugs
> 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.