On 4/11/23 14:58, Emre Hasegeli wrote:
>> 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_
> 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_ls
On Fri, Apr 7, 2023 at 11:06 PM Emre Hasegeli 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()
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.
Patch is a
