Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: row filtering for logical replication
Дата
Msg-id CAFiTN-vkDeP7+fhDcyPK7E_Hd+8SupkHrZc=Aq=xYSzhwAKGkQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Nov 29, 2021 at 5:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> > > I don't think it is a good idea to combine the row-filter from the
> > > publication that publishes just 'insert' with the row-filter that
> > > publishes 'updates'. We shouldn't apply the 'insert' filter for
> > > 'update' and similarly for publication operations. We can combine the
> > > filters when the published operations are the same. So, this means
> > > that we might need to cache multiple row-filters but I think that is
> > > better than having another restriction that publish operation 'insert'
> > > should also honor RI columns restriction.
> >
> > I am just wondering that if we don't combine filter in the above case
> > then what data we will send to the subscriber if the operation is
> > "UPDATE tbl1 SET a = 2, b=3", so in this case, we will apply only the
> > update filter i.e. a > 1 so as per that this will become the INSERT
> > operation because the old row was not passing the filter.
> >
>
> If we want, I think for inserts (new row) we can consider the insert
> filter as well but that makes it tricky to explain. I feel we can
> change it later as well if there is a valid use case for this. What do
> you think?

Yeah, that makes sense.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: pg_upgrade and publication/subscription problem