Re: [BUG]Update Toast data failure in logical replication - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [BUG]Update Toast data failure in logical replication
Date
Msg-id CAFiTN-vfa7dH0f9Za8YXuT+HvH4NfJqL6c5NYMtdn7NCO1XApA@mail.gmail.com
Whole thread Raw
In response to Re: [BUG]Update Toast data failure in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [BUG]Update Toast data failure in logical replication
List pgsql-hackers
On Sat, Jan 29, 2022 at 3:57 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Jan 28, 2022 at 12:16 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> + /*
> + * If it's a whole-tuple reference, say "not equal".  It's not really
> + * worth supporting this case, since it could only succeed after a
> + * no-op update, which is hardly a case worth optimizing for.
> + */
> + if (attrnum == 0)
> + continue;
> +
> + /*
> + * Likewise, automatically say "not equal" for any system attribute
> + * other than tableOID; we cannot expect these to be consistent in a
> + * HOT chain, or even to be set correctly yet in the new tuple.
> + */
> + if (attrnum < 0)
> + {
> + if (attrnum != TableOidAttributeNumber)
> + continue;
> + }
>
> These two cases need to be considered as the corresponding attribute
> is modified, so the attnum needs to be added in the bitmapset of
> modified attrs.

Yeah right.

>
> I have changed this and various other comments in the patch. I have
> modified the docs as well to reflect the changes. I thought of adding
> a test but I think the current test in toast.sql seems sufficient.
> Kindly let me know what you think of the attached? I think we should
> backpatch this till v10. What do you think?

Looks fine to me.

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



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: row filtering for logical replication
Next
From: Julien Rouhaud
Date:
Subject: Re: DELETE CASCADE