Message-ID: <0d7531c192859057c6aad54c89a8d453376bd00c.camel@cybertec.at>
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in
 pg_init_priv catalog table
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: =?ISO-8859-1?Q?H=FCseyin?= Demir <huseyin.d3r@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-bugs@lists.postgresql.org
Date: Mon, 22 Jun 2026 19:23:38 +0200
In-Reply-To: 
 <CAB5wL7ai8AiaFV6B8J=w6vK1Q6Z9Hmp_y3PFL2Zzpx6Y8xPZ2A@mail.gmail.com>
References: <19483-80de42dc4e62cfd6@postgresql.org>
	 <CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg@mail.gmail.com>
	 <104812.1780847519@sss.pgh.pa.us>
	 <CAB5wL7bo-7okBCJ24fdVn4UhnuPLPG22eQjaLJZ9GJtv0FEWMg@mail.gmail.com>
	 <CAB5wL7bunPCi93Bwi7zN_1gFAZhKLwS=Fsub91SW417xujGtNA@mail.gmail.com>
	 <CAB5wL7aKGFFEF1SM54GxvaQPH=7Bs=HuUCqi7F4Ve025+Z950A@mail.gmail.com>
	 <CAB5wL7aK6UaukMSegzEG68y0VrKOg7wFnPNRaDaHreBf2iVWag@mail.gmail.com>
	 <d305af372949be0c2c4155168ca7ba97e160bc52.camel@cybertec.at>
	 <5184088806e70ed5db7e83bd6540a016b3802c1d.camel@cybertec.at>
	 <CAB5wL7ZuFwu2Sd-xmn-w5-BbrKk_Mu_1ubYow_qaqFGhJOiMXw@mail.gmail.com>
	 <CAB5wL7ai8AiaFV6B8J=w6vK1Q6Z9Hmp_y3PFL2Zzpx6Y8xPZ2A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/0d7531c192859057c6aad54c89a8d453376bd00c.camel%40cybertec.at>
Precedence: bulk

On Mon, 2026-06-22 at 08:07 +0200, H=C3=BCseyin Demir wrote:
> > v4 applies the filter at all four sites where pg_dump queries pg_init_p=
rivs:
> > - getAggregates() =E2=80=94 WHERE clause comparison
> > - getFuncs() =E2=80=94 WHERE clause comparison
> > - getAdditionalACLs() =E2=80=94 SELECT expression (object-level initpri=
vs)
> > - PREPQUERY_GETCOLUMNACLS =E2=80=94 SELECT expression (column-level ini=
tprivs,
> > objsubid !=3D 0)
> >=20
> > Secondly to avoid duplicating the multi-line subquery at every call
> > site, I introduced a SAFE_INITPRIVS(col) macro.

Great, that's just what I had in mind.

> One question from my side: can't we use function instead of macro ?
> Would it be more accurate for future readers ?

That would work too, but if you do it in C rather than with the
preprocessor, you have to deal with string manipulation, which
will makes the patch more complicated.  I think it is better the
way it is now.

I'll mark the patch "ready for committer".

Since there have been very few reports of this problem, the question
remains if we need this patch at all, or of it should be backpatched.
My opinion is that it should; every upgrade or restore failure is
one too many.

Yours,
Laurenz Albe