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

On Thu, Aug 8, 2024 at 9:53 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.

Yes, existing code will work, no doubt about that. But generally we
explictly use XLogRecPtrIsInvalid if we need to include or exclude
lsn=0 in some logic. We do not consider 0 lsn for comparisons like
this which we currently have in get_flush_position. Thus stated for an
explicit check. But, yes, the current code will work.

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

Okay. Sounds reasonable.

thanks
Shveta