Re: row filtering for logical replication
От | Dilip Kumar |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAFiTN-teMxRqxyDzi07nF9-QotMy-NuAUtkFAa0NrD_8DRLiyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: row filtering for logical replication (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: row filtering for logical replication
|
Список | pgsql-hackers |
On Tue, Jul 20, 2021 at 3:12 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > Why? I think it would just need similar restrictions as we are > > > planning for Delete operation such that filter columns must be either > > > present in primary or replica identity columns. > > > > > > > How else would you turn UPDATE to INSERT? For UPDATE we only send the > > identity columns and modified columns, and the decision happens on the > > subscriber. > > > > Hmm, we log the entire new tuple and replica identity columns for the > old tuple in WAL for Update. And, we are going to use a new tuple for > Insert, so we have everything we need. > But for making that decision we need to apply the filter on the old rows as well right. So if we want to apply the filter on the old rows then either the filter should only be on the replica identity key or we need to use REPLICA IDENTITY FULL. I think that is what Tomas wants to point out. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: