Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Sergei Kornilov <sk@zsrv.org>
Cc: Peter Smith <smithpb2250@gmail.com>, pgsql-hackers@lists.postgresql.org, Önder Kalacı <onderkalaci@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Date: 2023-07-10T12:46:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Doc: Update the logical replication restriction w.r.t Replica Identity Full.
- 961cf5c9055f 17.0 landed
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 publication side (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 be performed. > 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.