Re: Unnecessary confirm work on logical replication

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Unnecessary confirm work on logical replication
Дата
Msg-id CAExHW5sHMUdwUZP-BiM=EXhUJRJBVpyYC3yukFkzG4LU9LTgZA@mail.gmail.com
обсуждение исходный текст
Ответ на Unnecessary confirm work on logical replication  (Emre Hasegeli <emre@hasegeli.com>)
Ответы Re: Unnecessary confirm work on logical replication  (Emre Hasegeli <emre@hasegeli.com>)
Список pgsql-hackers
On Fri, Apr 7, 2023 at 11:06 PM Emre Hasegeli <emre@hasegeli.com> wrote:
>
> I was reading the logical replication code and found a little
> unnecessary work we are doing.
>
> The confirmed_flushed_lsn cannot reasonably be ahead of the
> current_lsn, so there is no point of calling
> LogicalConfirmReceivedLocation() every time we update the candidate
> xmin or restart_lsn.

In fact, the WAL sender always starts reading WAL from restart_lsn,
which in turn is always <= confirmed_flush_lsn. While reading WAL, WAL
sender may read XLOG_RUNNING_XACTS WAL record with lsn <=
confirmed_flush_lsn. While processing XLOG_RUNNING_XACTS record it may
update its restart_lsn and catalog_xmin with current_lsn = lsn fo
XLOG_RUNNING_XACTS record. In this situation current_lsn <=
confirmed_flush_lsn.

Does that make sense?

--
Best Wishes,
Ashutosh Bapat



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Support logical replication of DDLs
Следующее
От: Zhang Mingli
Дата:
Сообщение: Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel