Re: [BUG]Update Toast data failure in logical replication

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUG]Update Toast data failure in logical replication
Date: 2021-06-02 09:39:52
Message-ID: CAFiTN-sD+eL4tDOmrBoy5VLihyyPwNycmw--oQOXNSGm52JzNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 2, 2021 at 2:37 PM tanghy(dot)fnst(at)fujitsu(dot)com
<tanghy(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Wed, Jun 2, 2021 2:44 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > Attached patch fixes that, I haven't yet added the test case. Once
> > someone confirms on the approach then I will add a test case to the
> > patch.
>
> key_tuple = heap_form_tuple(desc, values, nulls);
> *copy = true;
> ...
> key_tuple = toast_flatten_tuple(oldtup, desc);
> heap_freetuple(oldtup);
> }
> + /*
> + * If key tuple doesn't have any external data and key is not changed then
> + * just free the key tuple and return NULL.
> + */
> + else if (!key_changed)
> + {
> + heap_freetuple(key_tuple);
> + return NULL;
> + }
>
> return key_tuple;
> }
>
> I think "*copy = false" should be added before return NULL because we don't return a modified copy tuple here. Thoughts?

Yes, you are right. I will change it in the next version, along with
the test case.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tanghy.fnst@fujitsu.com 2021-06-02 09:50:51 tab-complete for CREATE TYPE ... SUBSCRIPT
Previous Message houzj.fnst@fujitsu.com 2021-06-02 09:33:26 RE: Parallel INSERT SELECT take 2