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

Hi Hüseyin,

v9 applies to master (86f7c82cf1) and builds warning-free. pg_dump.c,
meson.build and the test are identical to v8 plus my patch, so the delta
is the commit message, and all four points are in it. make check passes
in src/bin/pg_dump and src/bin/pg_upgrade, and under meson the test is
listed and passes.

I ran the case in the new commit-message paragraph as a real upgrade: a
16beta2 cluster, the extension from my last mail installed by a role that
was then REASSIGN OWNED, DROP OWNED and dropped, leaving

objoid | classoid | privtype | initprivs | owner
--------+----------+----------+---------------------------------+----------
16387 | pg_proc | e | {16384=X/16384} | postgres
16388 | pg_class | e | {16384=arwdDxtm/16384,=r/16384} | postgres

pg_upgrade to master without the patch fails in the restore with

ERROR: role "16384" does not exist

A --binary-upgrade dump of that cluster with the unpatched pg_dump has,
for the function,

SELECT pg_catalog.binary_upgrade_set_record_init_privs(true);
REVOKE ALL ON FUNCTION public.orphan_reset() FROM PUBLIC;
REVOKE ALL ON FUNCTION public.orphan_reset() FROM postgres;
SET SESSION AUTHORIZATION "16384";
GRANT ALL ON FUNCTION public.orphan_reset() TO "16384";
RESET SESSION AUTHORIZATION;
SELECT pg_catalog.binary_upgrade_set_record_init_privs(false);

With v9 the same upgrade goes through, the new cluster has no
pg_init_privs row for either object, and a plain dump of it carries the
REVOKE and the GRANT next to CREATE EXTENSION, as the paragraph says.

Nothing else from me; no open items.

Regards,
Rui