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
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 |