Re: Column Filtering in Logical Replication
От | Tomas Vondra |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | ec95d68e-495e-9e49-e34b-6a3d7f2e2abc@enterprisedb.com обсуждение исходный текст |
Ответ на | RE: Column Filtering in Logical Replication ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | pgsql-hackers |
On 3/14/22 12:12, houzj.fnst@fujitsu.com wrote: > On Monday, March 14, 2022 5:08 AM Tomas Vondra <tomas.vondra@enterprisedb.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. > Yeah, a test would be nice - I'll take a look later. 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). regards [1] https://www.postgresql.org/message-id/822a8e40-287c-59ff-0ea9-35eb759f4fe6%40enterprisedb.com -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: