| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Sergei Kornilov <sk(at)zsrv(dot)org> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Önder Kalacı <onderkalaci(at)gmail(dot)com> |
| Subject: | Re: doc: clarify the limitation for logical replication when REPILICA IDENTITY is FULL |
| Date: | 2023-07-13 13:06:49 |
| Message-ID: | CAA4eK1KcgV+FbG+RQLHnDTqMOS7g6fn=U289-+0FnUPjLmf8Mg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 11, 2023 at 2:17 PM Sergei Kornilov <sk(at)zsrv(dot)org> wrote:
>
> I think it's appropriate to add on the restrictions page. (But mentioning that this restriction is only for subscriber)
>
> If the list were larger, then the restrictions page could be divided into publisher and subscriber restrictions. But not for one very specific restriction.
>
Okay, how about something like: "The UPDATE and DELETE operations
cannot be applied on the subscriber for the published tables that
specify REPLICA IDENTITY FULL when the table has attributes with
datatypes (e.g point or box) that don't have a default operator class
for Btree or Hash. This won't be a problem if the table has a primary
key or replica identity defined for it."?
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan S. Katz | 2023-07-13 13:20:33 | Re: Incremental sort for access method with ordered scan support (amcanorderbyop) |
| Previous Message | Amit Langote | 2023-07-13 12:58:38 | Re: generic plans and "initial" pruning |