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: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Sabino Mullane <htamfids@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2026-06-22T05:44:45Z
Lists: pgsql-bugs
Attachments
- v4-0001-pg_dump-skip-dangling-initprivs.patch (application/octet-stream) patch v4-0001
Hi, > Further testing shows that changing this query isn't enough. > There are three more places where pg_dump queries pg_init_privs > (in getAggregates, getFuncs and dumpTable). > > So we'd have to use a similarly ugly query in all these places, > which doesn't seem particularly attractive and introduces > considerable code duplication. > > One approach I can think of is to have a macro SAFE_INITPRIVS > that contains the ugly subquery and is used in all these places. > > The other idea is to do some post-processing of the aclitems > found, but they are in string form and would need to get parsed > again, which doesn't look attractive either. Thanks for the feedback. I created a simple v4 patch to cover your feedback v4 applies the filter at all four sites where pg_dump queries pg_init_privs: - getAggregates() — WHERE clause comparison - getFuncs() — WHERE clause comparison - getAdditionalACLs() — SELECT expression (object-level initprivs) - PREPQUERY_GETCOLUMNACLS — SELECT expression (column-level initprivs, objsubid != 0) Secondly to avoid duplicating the multi-line subquery at every call site, I introduced a SAFE_INITPRIVS(col) macro. I tried to add more clean and detailed comments for future commits but please let me know if you have additional feedback on it. Regards, Demir.