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

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Date: 2026-06-21 05:47:33
Message-ID: 5184088806e70ed5db7e83bd6540a016b3802c1d.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, 2026-06-20 at 23:53 +0200, I wrote:
> I think that we need something like this fix, because a failing
> upgrade is a bug. For the same reason I think that the fix
> should be backpatched.
>
> I looked at your patch and found that the query you added doesn't
> cover the important case where the grantor is a non-existing role
>
> I suggest a query like this one: [...]

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.

Yours,
Laurenz Albe

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Michael Paquier 2026-06-20 22:51:25 Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =