Re: pg_upgrade: optimize replication slot caught-up check
| От | Masahiko Sawada |
|---|---|
| Тема | Re: pg_upgrade: optimize replication slot caught-up check |
| Дата | |
| Msg-id | CAD21AoD57iThMjAnBV6zBgoktRvzQnKw5HBefAARoHTBQVxAUw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_upgrade: optimize replication slot caught-up check (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: pg_upgrade: optimize replication slot caught-up check
|
| Список | pgsql-hackers |
On Tue, Jan 27, 2026 at 3:59 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > 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? > 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
Вложения
В списке pgsql-hackers по дате отправления: