Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table - Mailing list pgsql-bugs

From Laurenz Albe
Subject Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Date
Msg-id 5184088806e70ed5db7e83bd6540a016b3802c1d.camel@cybertec.at
Whole thread
In response to Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
List 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



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =
Next
From: Tim Goddard
Date:
Subject: Rule on table with DO ALSO increments sequences twice