Re: Found issues related with logical replication and 2PC
От | Amit Kapila |
---|---|
Тема | Re: Found issues related with logical replication and 2PC |
Дата | |
Msg-id | CAA4eK1L-r8OKGdBwC6AeXSibrjr9xKsg8LjGpX_PDR5Go-A9TA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Found issues related with logical replication and 2PC (shveta malik <shveta.malik@gmail.com>) |
Ответы |
Re: Found issues related with logical replication and 2PC
RE: Found issues related with logical replication and 2PC |
Список | 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.
В списке pgsql-hackers по дате отправления: