From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Jacob Champion <jchampion(at)timescale(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Subject: | Re: RFC: logical publication via inheritance root? |
Date: | 2023-06-21 10:28:28 |
Message-ID: | CAA4eK1+aB-PpY2c4ufE=t6gO4UyP-rimheq9D3BfyJpDfuBAWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 20, 2023 at 10:39 PM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
>
> On Fri, Jun 16, 2023 at 9:24 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> > The other idea that came across my mind was to provide some schema
> > mapping kind of feature on subscribers where we could route the tuples
> > from table X to table Y provided they have the same or compatible
> > schema. I don't know if this is feasible or how generally it will be
> > useful and whether any other DB (replication solution) provides such a
> > feature but I guess something like that would have helped your use
> > case.
>
> Yes, that may have also worked. Making it a subscriber-side feature
> requires tight coupling between the two peers, though. (For the
> timescaledb case, how does the subscriber know which new partitions
> belong to which root?
>
Yeah, the subscriber can't figure that out automatically. Users need
to provide the mapping manually.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Nazir Bilal Yavuz | 2023-06-21 11:04:17 | bgwriter doesn't flush WAL stats |
Previous Message | Michael Paquier | 2023-06-21 10:12:12 | Re: [BUG] recovery of prepared transactions during promotion can fail |