Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: row filtering for logical replication
Дата
Msg-id 7ad38afd-eb5b-47b7-8d1c-49a7b2637367@www.fastmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: row filtering for logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Tue, Nov 30, 2021, at 7:25 AM, Amit Kapila wrote:
On Tue, Nov 30, 2021 at 11:37 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> What about the initial table sync? during that, we are going to
> combine all the filters or we are going to apply only the insert
> filters?
>

AFAIK, currently, initial table sync doesn't respect publication
actions so it should combine all the filters. What do you think?
I agree. If you think that it might need a row to apply DML commands (UPDATE,
DELETE) in the future or that due to a row filter that row should be available
in the subscriber (INSERT-only case), it makes sense to send all rows that
satisfies any row filter.

The current code already works this way. All row filter are combined into a
WHERE clause using OR. If any of the publications don't have a row filter,
there is no WHERE clause.


--
Euler Taveira

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?