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

From Amit Kapila
Subject Re: [BUG]Update Toast data failure in logical replication
Date
Msg-id CAA4eK1KgZr=QSBE_Qh0Qfb2ma1Tc6+ZxkMaUHO7aC7b9WSCRaw@mail.gmail.com
Whole thread Raw
In response to Re: [BUG]Update Toast data failure in logical replication  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [BUG]Update Toast data failure in logical replication
List pgsql-hackers
On Tue, Aug 10, 2021 at 8:08 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2021-Jul-30, Amit Kapila wrote:
>
> Reading Dilip's last posted patch that day, I had some reservations
> about the API of ExtractReplicaIdentity.  The new argument makes for a
> very strange to explain behavior "return the key values if they are
> unchanged, *or* if they are toasted" ... ???
>

I think we can say it as "Return the key values if they are changed
*or* if they are toasted". Currently, we have an exception for Deletes
where the caller always passed key_changed as true, so maybe we can
have a similar exception when the tuple has toasted values. Can we
think of changing the flag to "key_required" instead of "key_changed"
and let the caller identify and set its value? For Deletes, it will
work the same but for Updates, the caller needs to compute it by
checking if any of the key columns are modified or has a toast value.
We can try to see if the caller can identify it cheaply along with
determining the modified_attrs as at that time we will anyway check
replica key attrs.

Currently, in proposed patch first, we check that the tuple has any
toast values and then it deforms and forms the new key tuple. After
that, it checks if the key has any toast values and then only decides
to return the tuple. If as described in the previous paragraph, we can
cheaply identify whether the key has toasted values, then we can avoid
deform/form cost in some cases. Also, I think we need to change the
Replica Identity description in the docs[1].

[1] - https://www.postgresql.org/docs/devel/sql-altertable.html

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Mahendra Singh Thalor
Date:
Subject: Re: Support reset of Shared objects statistics in "pg_stat_reset" function
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side