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

From tanghy.fnst@fujitsu.com
Subject RE: [BUG]Update Toast data failure in logical replication
Date
Msg-id OS0PR01MB6113D89BA71E6E1439073E69FB3E9@OS0PR01MB6113.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: [BUG]Update Toast data failure in logical replication  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [BUG]Update Toast data failure in logical replication  (Dilip Kumar <dilipbalaut@gmail.com>)
List 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 couldnt 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 didnt return NULL. There is no problem with this case on HEAD, but the patch modified its return value. Im not sure if it would bring new problems. Have you checked it?

 

Regards

Tang

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Decoding speculative insert with toast leaks memory
Next
From: "Joel Jacobson"
Date:
Subject: Re: security_definer_search_path GUC