Re: pg_upgrade and logical replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_upgrade and logical replication
Date
Msg-id CAA4eK1++Zyw0bTqRspo-tHNHoD0zUv1r5TY1mdMNM3UaZqE3Bg@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade and logical replication  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pg_upgrade and logical replication
List pgsql-hackers
On Mon, Jul 22, 2024 at 8:16 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
> > On Mon, Jul 22, 2024 at 7:35 AM Michael Paquier <michael@paquier.xyz> wrote:
> >> On Sat, Jul 20, 2024 at 09:03:07PM -0500, Nathan Bossart wrote:
> >> >> This is an extremely expensive way to perform that check, and so I'm
> >> >> wondering why we don't just do
> >> >>
> >> >>      SELECT count(*) FROM pg_catalog.pg_subscription;
> >> >>
> >> >> once in count_old_cluster_subscriptions().
> >> >
> >> > Like so...
> >
> > Isn't it better to directly invoke get_subscription_count() in
> > check_new_cluster_subscription_configuration() where it is required
> > rather than in a db-specific general function?
>
> IIUC the old cluster won't be running at that point.
>

Right, the other option would be to move it to the place where we call
check_old_cluster_for_valid_slots(), etc. Initially, it was kept in
the specific function (get_db_rel_and_slot_infos) as we were
mainlining the count at the per-database level but now as we are
changing that I am not sure if calling it from the same place is a
good idea. But OTOH, it is okay to keep it at the place where we
retrieve the required information from the old cluster.

One minor point is the comment atop get_subscription_count() still
refers to the function name as get_db_subscription_count().

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_upgrade and logical replication
Next
From: Michael Paquier
Date:
Subject: Re: Flush pgstats file during checkpoints