From: | "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [BUG]Update Toast data failure in logical replication |
Date: | 2021-06-01 06:59:00 |
Message-ID: | OS0PR01MB6113D89BA71E6E1439073E69FB3E9@OS0PR01MB6113.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-06-01 06:59:23 | Re: security_definer_search_path GUC |
Previous Message | Amit Kapila | 2021-06-01 06:55:38 | Re: Decoding speculative insert with toast leaks memory |