On Mon, Mar 14, 2022 at 7:02 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote: > > On 3/14/22 13:47, Amit Kapila wrote: > > On Mon, Mar 14, 2022 at 5:42 PM Tomas Vondra > > <tomas.von...@enterprisedb.com> wrote: > >> > >> On 3/14/22 12:12, houzj.f...@fujitsu.com wrote: > >>> On Monday, March 14, 2022 5:08 AM Tomas Vondra > >>> <tomas.von...@enterprisedb.com> wrote: > >> > >> Anyway, the fix does not address tablesync, as explained in [1]. I'm not > >> sure what to do about it - in principle, we could calculate which > >> relations to sync, and then eliminate "duplicates" (i.e. relations where > >> we are going to sync an ancestor). > >> > > > > As mentioned in my previous email [1], this appears to be a base code > > issue (even without row filter or column filter work), so it seems > > better to deal with it separately. It has been reported separately as > > well [2] where we found some similar issues. > > > > Right. I don't want to be waiting for that fix either, that'd block this > patch unnecessarily. If there are no other comments, I'll go ahead, > polish the existing patches a bit more and get them committed. We can > worry about this pre-existing issue later. >
I think the first two patches are ready to go. I haven't read the latest version in detail but I have in mind that we want to get this in for PG-15. -- With Regards, Amit Kapila.
