Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL
От | Amit Kapila |
---|---|
Тема | Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL |
Дата | |
Msg-id | CAA4eK1+iJN9hzyBr3OAYmhsHmUkLmoCb0swEATSEKyPTJzcxzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re:doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL
|
Список | pgsql-hackers |
On Mon, Jul 10, 2023 at 4:33 PM Sergei Kornilov <sk@zsrv.org> wrote: > > Is this restriction only for the subscriber? > > If we have not changed the replica identity and there is no primary key, then we forbid update and delete on the publicationside (a fairly common usage error at the beginning of using publications). > If we have replica identity FULL (the table has such a column), then on the subscription side, update and delete will beperformed. > In the above sentence, do you mean the publisher side? > But we will not be able to apply them on a subscription. Right? > If your previous sentence talks about the publisher and this sentence about the subscriber then what you are saying is correct. You can see the example in the email [1]. > This is an important difference for real use, when the subscriber is not necessarily postgresql - for example, debezium. > Can you explain the difference and problem you are seeing? As per my understanding, this is the behavior from the time logical replication has been introduced. [1] - https://www.postgresql.org/message-id/TYAPR01MB5866C7B6086EB74918910F74F527A%40TYAPR01MB5866.jpnprd01.prod.outlook.com -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: