Re: [BUG]Update Toast data failure in logical replication
От | Dilip Kumar |
---|---|
Тема | Re: [BUG]Update Toast data failure in logical replication |
Дата | |
Msg-id | CAFiTN-sK1qt+DawK9jV7RBCmvTx0quVhNj73yNyJCXBMO1+4DA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG]Update Toast data failure in logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [BUG]Update Toast data failure in logical replication
|
Список | pgsql-hackers |
On Thu, Jul 22, 2021 at 4:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Jun 3, 2021 at 5:15 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Wed, Jun 2, 2021 at 7:23 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote: > > > > > > > > On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > > > > Yes, you are right. I will change it in the next version, along with > > > > > the test case. > > > > > > > > > + /* > > > > + * if the key hasn't changed and we're only logging the key, we're done. > > > > + * But if tuple has external data then we might have to detoast the key. > > > > + */ > > > > This doesn't really mention why we need to detoast the key even when > > > > the key remains the same. I guess we can add some more details here. > > > > > > Noted, let's see what others have to say about fixing this, then I > > > will fix this along with one other pending comment and I will also add > > > the test case. Thanks for looking into this. > > > > I have fixed all the pending issues, I see there is already a test > > case for this so I have changed the output for that. > > > > IIUC, this issue occurs because we don't log the actual key value for > unchanged toast key. It is neither logged as part of old_key_tuple nor > for new tuple due to which we are not able to find it in the > apply-side when we searched it via FindReplTupleInLocalRel. Now, I > think it will work if we LOG the entire unchanged toasted value as you > have done in the patch but can we explore some other way to fix it. In > the subscriber-side, can we detect that the key column has toasted > value in the new tuple and try to first fetch it and then do the index > search for the fetched toasted value? I am not sure about the > feasibility of this but wanted to see if we can someway avoid logging > unchanged toasted key value as that might save us from additional WAL. Yeah if we can do this then it will be a better approach, I think as you mentioned we can avoid logging unchanged toast key data. I will investigate this next week and update the thread. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: