On Wed, Feb 7, 2018 at 6:00 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Feb 7, 2018 at 3:42 PM, amul sul <sula...@gmail.com> wrote: >> On Wed, Feb 7, 2018 at 3:03 PM, Amit Khandekar <amitdkhan...@gmail.com> >> wrote: >>> On 7 February 2018 at 13:53, amul sul <sula...@gmail.com> wrote: >>>> Hi, >>>> >>>> If an update of partition key involves tuple movement from one partition to >>>> another partition then there will be a separate delete on one partition and >>>> insert on the other partition made. >>>> >>>> In the logical replication if an update performed on the master and >>>> standby at >>>> the same moment, then replication worker tries to replicate delete + insert >>>> operation on standby. While replying master changes on standby for the >>>> delete >>>> operation worker will log "concurrent update, retrying" message (because >>>> the >>>> update on standby has already deleted) and move forward to reply the next >>>> insert operation. Standby update also did the same delete+insert is as >>>> part of >>>> the update of partition key in a result there will be two records inserted >>>> on >>>> standby. >>> >>> A quick thinking on how to resolve this makes me wonder if we can >>> manage to pass some information through logical decoding that the >>> delete is part of a partition key update. This is analogous to how we >>> set some information locally in the tuple by setting >>> tp.t_data->t_ctid.ip_blkid to InvalidBlockNumber. >>> >> >> +1, >> > > I also mentioned the same thing in the other thread [1], but I think > that alone won't solve the dual record problem as you are seeing. I > think we need to do something for next insert as you are suggesting. >
Can you please once check what was the behavior before Update Tuple routing patch (Commit-id: 2f178441) went in? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
