| From: | Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: logical replication restrictions |
| Date: | 2021-09-22 11:56:09 |
| Message-ID: | CAB-JLwYHqgqGM5e+_xos6-D-YnVGH31YDBQE_gnd+DNBxS2zOA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> oh okay, I think this can be useful in some cases where we want to avoid
> data loss similar to its use for physical standby. For example, if the user
> has by mistake truncated the table (or deleted some required data) on the
> publisher, we can always it from the subscriber if we have such a feature.
>
> Having said that, I am not sure if we can call it a restriction. It is
> more of a TODO kind of thing. It doesn't sound advisable to me to keep
> growing the current Restrictions page
>
OK, so, could you guide me where to start on this feature ?
regards,
Marcos
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergei Kornilov | 2021-09-22 12:11:10 | Re: extensible options syntax for replication parser? |
| Previous Message | Gareth Palmer | 2021-09-22 11:49:06 | Re: [PATCH] Implement INSERT SET syntax |