Re: row filtering for logical replication
От | Tomas Vondra |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | 4da2b027-4f80-f31f-1d06-6498e9760c2e@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: row filtering for logical replication
Re: row filtering for logical replication |
Список | pgsql-hackers |
On 7/14/21 4:52 PM, Alvaro Herrera wrote: > On 2021-Jul-14, Tomas Vondra wrote: > >> The way I'm thinking about this is that for INSERT and DELETE it's clear >> which row version should be used (because there's just one). And for UPDATE >> we could see that as DELETE + INSERT, and apply the same rule to each >> action. >> >> On the other hand, I can imagine cases where it'd be useful to send the >> UPDATE when the old row matches the condition and new row does not. > > In any case, it seems to me that the condition expression should be > scanned to see which columns are used in Vars (pull_varattnos?), and > verify if those columns are in the REPLICA IDENTITY; and if they are > not, raise an error. Most of the time the REPLICA IDENTITY is going to > be the primary key; but if the user wants to use other columns in the > expression, we can HINT that they can set REPLICA IDENTITY FULL. > Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps we could ignore this for subscriptions without DELETE. 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. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: