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

From Euler Taveira
Subject Re: [BUG]Update Toast data failure in logical replication
Date
Msg-id ec368900-6f29-492c-838a-da6093eef932@www.fastmail.com
Whole thread Raw
In response to RE: [BUG]Update Toast data failure in logical replication  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Responses Re: [BUG]Update Toast data failure in logical replication
List pgsql-hackers
On Tue, Feb 8, 2022, at 10:18 PM, tanghy.fnst@fujitsu.com wrote:
2)
+ /*
+ * Check if the old tuple's attribute is stored externally and is a
+ * member of external_cols.
+ */
+ if (VARATT_IS_EXTERNAL((struct varlena *) DatumGetPointer(value1)) &&
+ bms_is_member(attrnum - FirstLowInvalidHeapAttributeNumber,
+   external_cols))
+ *has_external = true;

If has_external is already true, it seems we don't need this check, so should we
check has_external first?
Is it worth it? I don't think so. It complicates a non-critical path. In
general, the condition will be executed once or twice.


--
Euler Taveira

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: row filtering for logical replication
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURR