Re: Unnecessary confirm work on logical replication

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: emre(at)hasegeli(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unnecessary confirm work on logical replication
Date: 2023-04-10 11:25:58
Message-ID: CAExHW5sHMUdwUZP-BiM=EXhUJRJBVpyYC3yukFkzG4LU9LTgZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 7, 2023 at 11:06 PM Emre Hasegeli <emre(at)hasegeli(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2023-04-10 12:48:57 Re: pgsql: psql: add an optional execution-count limit to \watch.
Previous Message Amit Kapila 2023-04-10 11:20:09 Re: Support logical replication of DDLs