Re: Column Filtering in Logical Replication

On 3/15/22 09:30, Tomas Vondra wrote:
>
>
> On 3/15/22 05:43, Amit Kapila wrote:
>> On Mon, Mar 14, 2022 at 4:42 PM houzj(dot)fnst(at)fujitsu(dot)com
>> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>>>
>>> On Monday, March 14, 2022 5:08 AM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>>>
>>>> On 3/12/22 05:30, Amit Kapila wrote:
>>>>>> ...
>>>>>
>>>>> Okay, please find attached. I have done basic testing of this, if we
>>>>> agree with this approach then this will require some more testing.
>>>>>
>>>>
>>>> Thanks, the proposed changes seem like a clear improvement, so I've
>>>> added them, with some minor tweaks (mostly to comments).
>>>
>>> Hi,
>>>
>>> Thanks for updating the patches !
>>> And sorry for the row filter bug caused by my mistake.
>>>
>>> I looked at the two fixup patches. I am thinking would it be better if we
>>> add one testcase for these two bugs? Maybe like the attachment.
>>>
>>
>> Your tests look good to me. We might want to add some comments for
>> each test but I guess that can be done before committing. Tomas, it
>> seems you are planning to push these bug fixes, do let me know if you
>> want me to take care of these while you focus on the main patch? I
>> think the first patch needs to be backpatched till 13 and the second
>> one is for just HEAD.
>>
>
> Yeah, I plan to push the fixes later today. I'll polish them a bit
> first, and merge the tests (shared by Hou zj) into the patches etc.
>

I've pushed (and backpatched to 13+) the fix for the publish_as_relid
issue, including the test. I tweaked the test a bit, to check both
orderings of the publication list.

While doing that, I discovered yet ANOTHER bug in the publish_as_relid
loop, affecting 12+13. There was a break once all actions were
replicated, but skipping additional publications ignores the fact that
the publications may replicate a different (higher-up) ancestor.

I removed the break, if anyone thinks this optimization is worth it we
could still do that once we replicate the top-most ancestor.

I'll push the second fix soon.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company