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

tanghy <tanghy.fnst@fujitsu.com>

From: "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>

To: Dilip Kumar <dilipbalaut@gmail.com>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2021-06-01T06:59:00Z

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 →

WAL log unchanged toasted replica identity key attributes.
- 5e01001ffb38 15.0 landed
- b5e060473273 10.21 landed
- 1cd5802ac69a 11.16 landed
- ce349cf176e2 12.11 landed
- caa231be97df 13.7 landed
- 04645bbcae72 14.3 landed
Add new wal_level, logical, sufficient for logical decoding.
- e55704d8b2fe 9.4.0 cited
Add the notion of REPLICA IDENTITY for a table.
- 07cacba983ef 9.4.0 cited

Hi

I have some questions with your patch. Here are two cases I used to check the bug.

Case1(PK toasted_key is short), data could be synchronized on HEAD.
---------------
INSERT INTO toasted_key(toasted_key, toasted_col1) VALUES('111', repeat('9876543210', 200));
UPDATE toasted_key SET toasted_col2 = toasted_col1;
---------------

Case2(PK toasted_key is very long), data couldn’t be synchronized on HEAD.(which is the bug)
---------------
INSERT INTO toasted_key(toasted_key, toasted_col1) VALUES(repeat('9876543210', 200), '111');
UPDATE toasted_key SET toasted_col2 = toasted_col1;
---------------

So I think the bug is only related with the length of primary key.
I noticed that in case1, ExtractReplicaIdentity function returned NULL on HEAD. But after your fix, it didn’t return NULL. There is no problem with this case on HEAD, but the patch modified its return value. I’m not sure if it would bring new problems. Have you checked it?

Regards
Tang