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

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.