Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL
Date
Msg-id CAA4eK1+iJN9hzyBr3OAYmhsHmUkLmoCb0swEATSEKyPTJzcxzQ@mail.gmail.com
Whole thread Raw
In response to Re:doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL  (Sergei Kornilov <sk@zsrv.org>)
Responses Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: [PATCH] Slight improvement of worker_spi.c example
Next
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Infinite loop while acquiring new TOAST Oid