Re: pg_upgrade: optimize replication slot caught-up check
| От | Amit Kapila |
|---|---|
| Тема | Re: pg_upgrade: optimize replication slot caught-up check |
| Дата | |
| Msg-id | CAA4eK1++qCG3prg-VhqbC4n2-8Us=cD-TW_3UEWyfM2VRY407w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_upgrade: optimize replication slot caught-up check (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: pg_upgrade: optimize replication slot caught-up check
|
| Список | 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 по дате отправления: