| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(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 11:59:18 |
| Message-ID: | CAA4eK1++qCG3prg-VhqbC4n2-8Us=cD-TW_3UEWyfM2VRY407w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jakub Wartak | 2026-01-27 12:06:13 | Re: pg_stat_io_histogram |
| Previous Message | Dean Rasheed | 2026-01-27 11:55:00 | Re: could not find replacement targetlist entry for attno -6 |