On Wed, Aug 7, 2024 at 3:32 PM Amit Kapila <amit.kapil...@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.