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