public inbox for [email protected]
help / color / mirror / Atom feedFrom: Hüseyin Demir <[email protected]>
To: Tom Lane <[email protected]>
Cc: Greg Sabino Mullane <[email protected]>
Cc: [email protected]
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
Date: Thu, 11 Jun 2026 07:49:05 +0200
Message-ID: <CAB5wL7bo-7okBCJ24fdVn4UhnuPLPG22eQjaLJZ9GJtv0FEWMg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAKAnmmLYXcBSV8i5MVuiwu8tkX-JDGmZtJ38_YbdUTwoDW7xKg@mail.gmail.com>
<[email protected]>
> The orphaned-rows problem shouldn't exist in v17 and later (see
> 534287403, 35dd40d34, and related commits). The OP is apparently
> complaining about an upgrade from v14, where such rows could exist.
Yes I was working on upgrading the PostgreSQL version from v14 to v18
and was able to solve the problem by removing the danling records from
pg_init_privs.
> I wonder if it'd be sane for pg_dump to just skip dangling role
> references in pg_init_privs.
It will change the behavior of pg_dump and it's a general purpose tool
because when we instruct pg_dump to filter orphan records it will
change the content in the system catalogs.
For now I suppose we have two options: either pg_upgrade or pg_dump.
Regards.
Tom Lane <[email protected]>, 7 Haz 2026 Paz, 17:52 tarihinde şunu yazdı:
>
> Greg Sabino Mullane <[email protected]> writes:
> >> 5. Verify orphan records remain in pg_init_privs:
>
> > 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?
>
> The orphaned-rows problem shouldn't exist in v17 and later (see
> 534287403, 35dd40d34, and related commits). The OP is apparently
> complaining about an upgrade from v14, where such rows could exist.
>
> I don't especially care for the proposed fix of making pg_upgrade
> refuse to run. Manually correcting such situations would be tedious
> and error-prone. Plus, it's inconsistent with what we did about
> related issues with role GRANTs (see 29d75b25b and 74b4438a7).
> I wonder if it'd be sane for pg_dump to just skip dangling role
> references in pg_init_privs.
>
> regards, tom lane
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: BUG #19483: pg_upgrade fails with orphan records in pg_init_priv catalog table
In-Reply-To: <CAB5wL7bo-7okBCJ24fdVn4UhnuPLPG22eQjaLJZ9GJtv0FEWMg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox