Hi All, Attaching POC patch that throws an error in the case of a concurrent update to an already deleted tuple due to UPDATE of partition key.
In a normal update new tuple is linked to the old one via ctid forming a chain of tuple versions but UPDATE of partition key move tuple from one partition to an another partition table which breaks that chain. Consider a following concurrent update case where one session trying to update a row that's locked for a concurrent update by the another session cause tuple movement to the another partition. create table foo (a int2, b text) partition by list (a); create table foo1 partition of foo for values IN (1); create table foo2 partition of foo for values IN (2); insert into foo values(1, 'ABC'); ----------- session 1 ----------- postgres=# begin; BEGIN postgres=# update foo set a=2 where a=1; UPDATE 1 ----------- session 2 ----------- postgres=# update foo set b='EFG' where a=1; ….. wait state …… ----------- session 1 ----------- postgres=# commit; COMMIT ----------- session 2 ----------- UPDATE 0 This UPDATE 0 is the problematic, see Greg Stark's update explains why we need an error. To throw an error we need an indicator that the targeted row has been already moved to the another partition, and for that setting a ctid.ip_blkid to InvalidBlockId looks viable option for now. The attached patch incorporates the following logic suggested by Amit Kapila: "We can pass a flag say row_moved (or require_row_movement) to heap_delete which will in turn set InvalidBlockId in ctid instead of setting it to self. Then the ExecUpdate needs to check for the same and return an error when heap_update is not successful (result != HeapTupleMayBeUpdated)." 1] https://postgr.es/m/CAJ3gD9do9o2ccQ7j7%2BtSgiE1REY65XRiMb%3DyJO3u3QhyP8EEPQ%40mail.gmail.com 2] With https://postgr.es/m/CAJ3gD9fzD4jBpv+zXqZYnW=h9JXUFG9E7NGdA9gR_JJbOj=q...@mail.gmail.com patch applied. 3] https://postgr.es/m/CAM-w4HPis7rbnwi%2BoXjnouqMSRAC5DeVcMdxEXTMfDos1kaYPQ%40mail.gmail.com 4] https://postgr.es/m/CAA4eK1KEZQ%2BCyXbBzfn1jFHoEfa_OemDLhLyy7xfD1QUZLo1DQ%40mail.gmail.com Regards, Amul
Description: Binary data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers