Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: row filtering for logical replication
Дата
Msg-id cd3ee2ae-97e0-45c1-ab33-b2bc03760887@www.fastmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Ответы Re: row filtering for logical replication
Список pgsql-hackers
On Wed, Jul 14, 2021, at 12:08 PM, Tomas Vondra wrote:
Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps 
we could ignore this for subscriptions without DELETE.
... and UPDATE. It seems we have a consensus to use old row in the row filter
for UPDATEs. I think you meant publication.

The other question is when to check/enforce this. I guess we'll have to 
do that during decoding, not just when the publication is being created, 
because the user can do ALTER TABLE later.
I'm afraid this check during decoding has a considerable cost. If we want to
enforce this condition, I suggest that we add it to CREATE PUBLICATION, ALTER
PUBLICATION ... ADD|SET TABLE and ALTER TABLE ... REPLICA IDENTITY. Data are
being constantly modified; schema is not.


--
Euler Taveira

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

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: free C string
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SI messages sent when excuting ROLLBACK PREPARED command