Re: Found issues related with logical replication and 2PC - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Found issues related with logical replication and 2PC
Date
Msg-id CAA4eK1L-r8OKGdBwC6AeXSibrjr9xKsg8LjGpX_PDR5Go-A9TA@mail.gmail.com
Whole thread Raw
In response to Re: Found issues related with logical replication and 2PC  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Found issues related with logical replication and 2PC
RE: Found issues related with logical replication and 2PC
List pgsql-hackers
On Thu, Aug 8, 2024 at 8:54 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Wed, Aug 7, 2024 at 5:43 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> > So, if my
> > analysis is correct, this shouldn't be a bug and ideally, we should
> > update local_end LSN as InvalidXLogRecPtr and add appropriate
> > comments.
>
> Okay, we can do that. Then get_flush_position() can also be changed to
> *explicitly* deal with the case where local_end is InvalidXLogRecPtr.
>

AFAICS, it should be handled without any change as the value of
InvalidXLogRecPtr is 0. So, it should be less than equal to the
local_flush position.

> Having said that, even though it is not a bug, shouldn't we still have
> the correct mapping updated in lsn_mapping? When remote_end is PREPARE
> Or COMMIT_PREPARED, local_end should also point to the same?
>

Ideally yes, but introducing a new global variable just for this
purpose doesn't sound advisable. We can add in comments that in the
future, if adding such a variable serves some purpose then we can
surely extend the functionality.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences
Next
From: Amit Kapila
Date:
Subject: Re: Found issues related with logical replication and 2PC