Re: pg_upgrade: optimize replication slot caught-up check

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>, Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-29T20:45:14Z
Lists: pgsql-hackers

Attachments

On Wed, Jan 28, 2026 at 10:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jan 28, 2026 at 2:06 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > I missed fixing one place. Attached the new version.
> >
>
> One question/comment on following change:
> + bool use_fast_caught_up_check;
> +
> + logical_slot_infos_query = get_old_cluster_logical_slot_infos_query(cluster,
> + &use_fast_caught_up_check);
> +
>   upgrade_task_add_step(task,
>     logical_slot_infos_query,
>     process_old_cluster_logical_slot_infos,
>     true, NULL);
> +
> + /*
> + * Check whether slots have consumed all WAL records efficiently by
> + * using another query, if not during a live_check.
> + */
> + if (use_fast_caught_up_check && !user_opts.live_check)
> + {
>
> Won't this lead to two steps to set caught_up for slots in PG19 and
> following versions? If so, is it possible to use just one step even
> for PG19 and following versions?

Yes, it seems like a good simplification. I've updated the patch accordingly.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Commits

  1. pg_upgrade: Optimize logical replication slot caught-up check.

  2. pg_upgrade: Parallelize retrieving relation information.

  3. Migrate logical slots to the new node during an upgrade.