Re: Found issues related with logical replication and 2PC

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Found issues related with logical replication and 2PC
Date: 2024-08-08 04:23:26
Message-ID: CAA4eK1L-r8OKGdBwC6AeXSibrjr9xKsg8LjGpX_PDR5Go-A9TA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 8, 2024 at 8:54 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Wed, Aug 7, 2024 at 5:43 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2024-08-08 04:44:31 Re: pgsql: Introduce hash_search_with_hash_value() function
Previous Message Amit Kapila 2024-08-08 03:55:04 Re: Logical Replication of sequences