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

On Wed, Aug 7, 2024 at 3:32 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I also think so. Additionally, I feel a test case (or some description
> of the bug that can arise) should be provided for issue-1.
>

IIUC, the problem could be that we would end up updating the wrong
local_end LSN in lsn_mappings via store_flush_position(). Then
get_flush_position() could end up computing the wrong flush position
and send the confirmation of flush to the publisher even when it is
not flushed. This ideally could lead to a situation where the prepared
transaction is not flushed to disk on the subscriber and because
publisher would have gotten the confirmation earlier than required, it
won't send the prepared transaction again. I think this theory is not
true for prepare transactions because we always flush WAL of prepare
even for asynchronous commit mode. See EndPrepare(). 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.

--
With Regards,
Amit Kapila.