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

Hi Hüseyin,

v7 is a straight rebase of v6, so the two points I raised about the test on
v6 [1] are still open -- I suspect they just got buried in the performance
discussion that followed. Since Laurenz's 20k-table run has this looking close
to going in, re-flagging both, re-tested on v7:

1) The test still doesn't run at all here. The four aclitem literals build the
grantor/grantee by concatenating current_user unquoted:

ARRAY[('ghost_grantee=X/' || current_user)::aclitem]

My bootstrap superuser is "rui.zhao", so on v7 the setup dies before a single
assertion runs:

error running SQL: 'psql:<stdin>:18: ERROR: role "rui" does not exist'

aclitemin stops parsing the grantor at the dot. Any cluster whose superuser name
needs quoting (a dot, uppercase, ...) hits this. Wrapping the four literals in
quote_ident(current_user) makes it pass 12/12 here.

2) The PUBLIC case (grantee = 0) is still uncovered. I ran the SAFE_INITPRIVS
expression over crafted values to check that branch, and it behaves correctly in
both directions:

{=X/super} -> {=X/super} PUBLIC grant, valid grantor: kept
{=X/16384} -> NULL PUBLIC grant, dangling
grantor: dropped
{alice=X/super} -> {alice=X/super}
{16384=X/super} -> NULL dangling grantee: dropped

so it's a coverage gap rather than a bug: "ace.grantee <> 0" is the one part of
the filter with no test behind it. A case in each direction would close it.

[1] https://postgr.es/m/CAHWVJhHB%2BtunzZLJcbERKb2G%2Bt-uw53MP3znU57STVa%2BsZdQ2Q%40mail.gmail.com

Thanks,
Rui