MIME-Version: 1.0
References: <19483-80de42dc4e62cfd6@postgresql.org>
In-Reply-To: <19483-80de42dc4e62cfd6@postgresql.org>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Wed, 20 May 2026 09:06:58 -0400
Message-ID: 
 <CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg@mail.gmail.com>
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv
 catalog table
To: huseyin.d3r@gmail.com, pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000a5c0ae06523f7a95"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg%40mail.gmail.com>
Precedence: bulk

--000000000000a5c0ae06523f7a95
Content-Type: text/plain; charset="UTF-8"

>
> PostgreSQL version: 18.3
> ...

5. Verify orphan records remain in pg_init_privs:erprise Postgres Software
> Products & Tech Support
>

Thanks for providing a failing use case. I ran this on a 18.3 server and
found no orphaned rows - but I used the pg_stat_statements extension
instead of pg_wait_sampling. Could you try your experiment using
pg_stat_statements? And could you also show us the contents of the errant
rows in pg_init_privs for the failing case?

--000000000000a5c0ae06523f7a95
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">PostgreSQL version: 18.3<br>...</b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">5. Verify orpha=
n records remain in pg_init_privs:erprise Postgres Software Products &amp; =
Tech Support<br></blockquote><div><br></div><div>Thanks for providing a fai=
ling use case. I ran this on a 18.3 server and found no orphaned rows - but=
 I used the pg_stat_statements extension instead of pg_wait_sampling. Could=
 you try your experiment using pg_stat_statements? And could you also show =
us the contents of the errant rows in pg_init_privs for the failing case?</=
div><div><br></div><div>=C2=A0</div></div><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><br></div></div></div></div>

--000000000000a5c0ae06523f7a95--