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

Euler Taveira <euler@eulerto.com>

From: "Euler Taveira" <euler@eulerto.com>
To: "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, "Amit Kapila" <amit.kapila16@gmail.com>, "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Cc: "Dilip Kumar" <dilipbalaut@gmail.com>, "Michael Paquier" <michael@paquier.xyz>, "Petr Jelinek" <petr.jelinek@enterprisedb.com>, "Peter Eisentraut" <peter.eisentraut@enterprisedb.com>, "Tomas Vondra" <tomas.vondra@enterprisedb.com>, "Andres Freund" <andres@anarazel.de>, "Kuntal Ghosh" <kuntalghosh.2007@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-02-09T01:46:33Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. WAL log unchanged toasted replica identity key attributes.

  2. Add new wal_level, logical, sufficient for logical decoding.

  3. Add the notion of REPLICA IDENTITY for a table.

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
EDB   https://www.enterprisedb.com/