| 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
| 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 = |