Re: Found issues related with logical replication and 2PC
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2024-08-08T04:23:26Z
Lists: pgsql-hackers
On Thu, Aug 8, 2024 at 8:54 AM shveta malik <shveta.malik@gmail.com> wrote: > > On Wed, Aug 7, 2024 at 5:43 PM Amit Kapila <amit.kapila16@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. > 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.
Commits
-
Change the misleading local end_lsn for prepared transactions.
- 701cf1e3174d 18.0 landed