On Thu, Aug 8, 2024 at 9:53 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Aug 8, 2024 at 8:54 AM shveta malik <shveta.ma...@gmail.com> wrote: > > > > On Wed, Aug 7, 2024 at 5:43 PM Amit Kapila <amit.kapil...@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
