On Tue, Feb 6, 2018 at 7:05 PM, amul sul <sulamul@gmail.com> wrote:
> On Sun, Feb 4, 2018 at 10:47 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Fri, Feb 2, 2018 at 2:11 PM, amul sul <sulamul@gmail.com> wrote:
>>> On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila <amit.kapila16@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=Ph60ZQ@mail.gmail.com
Regards,
Amul Sul