Re: pg_upgrade: optimize replication slot caught-up check - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_upgrade: optimize replication slot caught-up check
Date
Msg-id CAA4eK1++qCG3prg-VhqbC4n2-8Us=cD-TW_3UEWyfM2VRY407w@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade: optimize replication slot caught-up check  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: pg_upgrade: optimize replication slot caught-up check
List pgsql-hackers
On Fri, Jan 23, 2026 at 2:04 AM Masahiko Sawada <sawada.mshk@gmail.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?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: could not find replacement targetlist entry for attno -6
Next
From: Jakub Wartak
Date:
Subject: Re: pg_stat_io_histogram