Re: pg_upgrade: optimize replication slot caught-up check

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade: optimize replication slot caught-up check
Date: 2026-01-27 20:04:46
Message-ID: CAD21AoD57iThMjAnBV6zBgoktRvzQnKw5HBefAARoHTBQVxAUw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 27, 2026 at 3:59 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Jan 23, 2026 at 2:04 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
>
> I haven't reviewed v7 in detail but while glancing, I noticed a few
> minor comments:
>
> 1.
> + * Returns the last LSN decodable WAL record's LSN if found, otherwise
> + * returns InvalidXLogRecPtr.
> */
> -bool
> -LogicalReplicationSlotHasPendingWal(XLogRecPtr end_of_wal)
> +XLogRecPtr
> +LogicalReplicationSlotHasPendingWal(XLogRecPtr end_of_wal,
> + XLogRecPtr scan_cutoff_lsn)
>
> The function name suggests that it will return boolean (due to 'Has'
> in its name) but after this change that is not true.
>
> 2.
> We
> + * also use the maximum confirmed_flush_lsn as an early scan
> + * cutoff; finding a decodable WAL record beyond this point
> + * implies that no slot has caught up.
> + *
>
> In this comment, it is not clear if the maximum confirmed_flush_lsn is
> among all logical slots (of current database) or what?
>

Thank you for the comments!

I've incorporated these comments I got so far.

Amit, are you planning to review the patch in detail? If so, I want to
incorporate comments before the push.

Regards,

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

Attachment Content-Type Size
v8-0001-pg_upgrade-Optimize-replication-slot-caught-up-ch.patch application/octet-stream 20.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2026-01-27 20:10:19 Re: Mystery with REVOKE PRIVILEGE
Previous Message Jeff Davis 2026-01-27 19:44:36 Re: Remaining dependency on setlocale()