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 perhapswe 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 todo 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.
В списке pgsql-hackers по дате отправления: