| 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-20 21:53:01 |
| Message-ID: | d305af372949be0c2c4155168ca7ba97e160bc52.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, 2026-06-19 at 09:40 +0200, Hüseyin Demir wrote:
> Found a problem and fixed it quickly.
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
(that is, the original extension owner was dropped).
The grantor appears in SET SESSION AUTHORIZATION commands in the
dump, which make the restore and consequently the upgrade fail.
I suggest a query like this one:
SELECT pip.objoid, pip.classoid, pip.objsubid, pip.privtype,
NULLIF(
ARRAY(
SELECT elt FROM pg_catalog.unnest(pip.initprivs) AS elt
/* that is valid, that is, there is not ... */
WHERE NOT EXISTS (
/* ... a non-existing grantor ... */
SELECT 1 FROM pg_catalog.aclexplode(ARRAY[elt]) ace
WHERE NOT EXISTS (
SELECT 1 FROM pg_catalog.pg_roles AS r1
WHERE r1.oid = ace.grantor
)
/* ... or a non-existing grantee that isn't 0 */
OR ace.grantee <> 0
AND NOT EXISTS (
SELECT 1 FROM pg_catalog.pg_roles AS r2
WHERE r2.oid = ace.grantee
)
)
),
ARRAY[]::pg_catalog.aclitem[]
) AS initprivs
FROM pg_catalog.pg_init_privs pip;
You see that I added some comments, because the query is almost
incomprehensible. I couldn't think of a more elegant solution.
I think that you also should add an extensive code comment that
explains why this hack is needed.
I am undecided if the regression test with the artificially created
broken initial privileges is a good idea or not. After all, we are
not testing the real thing here (for example, the test didn't catch
the omission described above).
I am attaching a test extension that I installed in a v14 database
to test your patch; perhaps you'll find it useful. It creates all
kinds of objects that have an ACL. Dropping the role that created
the extension leaves various junk entries in pg_init_privs that you
can use to test your patch.
Yours,
Laurenz Albe
| Attachment | Content-Type | Size |
|---|---|---|
| ext.tgz | application/x-compressed-tar | 1.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next 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 = |
| Previous Message | Álvaro Herrera | 2026-06-20 16:58:27 | Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions = |