From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, vignesh C <vignesh21(at)gmail(dot)com>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Multi-Master Logical Replication |
Date: | 2022-05-31 14:06:35 |
Message-ID: | YpYg608FcI+knMTw@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 25, 2022 at 10:32:50PM -0400, Bruce Momjian wrote:
> On Wed, May 25, 2022 at 12:13:17PM +0530, Amit Kapila wrote:
> > > You still have not answered my question above. "Without these features,
> > > what workload would this help with?" You have only explained how the
> > > patch would fix one of the many larger problems.
> > >
> >
> > It helps with setting up logical replication among two or more nodes
> > (data flows both ways) which is important for use cases where
> > applications are data-aware. For such apps, it will be beneficial to
>
> That does make sense, thanks.
Uh, thinking some more, why would anyone set things up this way ---
having part of a table being primary on one server and a different part
of the table be a subscriber. Seems it would be simpler and safer to
create two child tables and have one be primary on only one server.
Users can access both tables using the parent.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2022-05-31 14:10:13 | Re: PostgreSQL Limits: maximum number of columns in SELECT result |
Previous Message | Dave Cramer | 2022-05-31 14:02:48 | Re: PostgreSQL Limits: maximum number of columns in SELECT result |