On Tue, Feb 6, 2018 at 7:05 PM, amul sul <sula...@gmail.com> wrote: > On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> On Fri, Feb 2, 2018 at 2:11 PM, amul sul <sula...@gmail.com> wrote: >>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila <amit.kapil...@gmail.com> >>> wrote: >>> [....] >>>> I think you can manually (via debugger) hit this by using >>>> PUBLICATION/SUBSCRIPTION syntax for logical replication. I think what >>>> you need to do is in node-1, create a partitioned table and subscribe >>>> it on node-2. Now, perform an Update on node-1, then stop the logical >>>> replication worker before it calls heap_lock_tuple. Now, in node-2, >>>> update the same row such that it moves the row. Now, continue the >>>> logical replication worker. I think it should hit your new code, if >>>> not then we need to think of some other way. >>>> >>> >>> I am able to hit the change log using above steps. Thanks a lot for the >>> step by step guide, I really needed that. >>> >>> One strange behavior I found in the logical replication which is >>> reproducible >>> without attached patch as well -- when I have updated on node2 by keeping >>> breakpoint before the heap_lock_tuple call in replication worker, I can see >>> a duplicate row was inserted on the node2, see this: >>> >> .. >>> >>> I am thinking to report this in a separate thread, but not sure if >>> this is already known behaviour or not. >>> >> >> I think it is worth to discuss this behavior in a separate thread. >> However, if possible, try to reproduce it without partitioning and >> then report it. >> > Logical replication behavior for the normal table is as expected, this happens > only with partition table, will start a new thread for this on hacker. > Posted on hackers : https://postgr.es/m/CAAJ_b94bYxLsX0erZXVH-anQPbWqcYUPWX4xVRa1YJY=ph6...@mail.gmail.com
Regards, Amul Sul