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
|
Список | 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 по дате отправления: