Hi,
> v3 also fixes a nasty uninitialized stack variable, along with a bad
> collation assumption I made.
I decided to take a closer look at 0001.
Since pg_get_relation_publishing_info() is exposed to the users I
think it should be described in a bit more detail than:
```
+ descr => 'get
On Wed, Jun 21, 2023 at 3:28 AM Amit Kapila wrote:
> On Tue, Jun 20, 2023 at 10:39 PM Jacob Champion
> wrote:
> > 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
> >
On Tue, Jun 20, 2023 at 10:39 PM Jacob Champion wrote:
>
> On Fri, Jun 16, 2023 at 9:24 PM Amit Kapila 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
On Fri, Jun 16, 2023 at 9:24 PM Amit Kapila wrote:
> > Is there an alternative implementation I'm missing, maybe, or a way to
> > make this feature more generally applicable? "We have table Y and want
> > it to be migrated as part of table X" seems to fall squarely under the
> > logical
On Sat, Jun 17, 2023 at 1:51 AM Jacob Champion wrote:
>
> On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila wrote:
>
> > > But if it's because you've implemented a partitioning scheme of your
> > > own (the docs still list reasons you might want to [2], even today),
> > > and all you ever really do is
On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila wrote:
> On Sat, Apr 1, 2023 at 5:06 AM Jacob Champion wrote:
> > I think it comes down to why an inheritance scheme was used. If it's
> > because you want to group rows into named, queryable subsets (e.g. the
> > "cities/capitals" example in the docs
On Sat, Apr 1, 2023 at 5:06 AM Jacob Champion wrote:
>
> On Fri, Mar 31, 2023 at 3:17 PM Peter Smith wrote:
>
> > Outside the scope of special TimescaleDB tables and the speculated
> > pg_partman old-style table migration, will this proposed new feature
> > have any other application? In other
On 4/4/23 08:14, Jacob Champion wrote:
> Yes, sorry -- after 062a84442, the architecture needs to change in a
> way that I'm still working through. I've moved the patch to Waiting on
> Author while I figure out the rebase.
Okay -- that took longer than I wanted, but here's a rebased patchset
that
On Mon, Apr 3, 2023 at 8:53 PM Peter Smith wrote:
>
> FYI, the WIP patch does not seem to apply cleanly anymore using the latest
> HEAD.
Yes, sorry -- after 062a84442, the architecture needs to change in a
way that I'm still working through. I've moved the patch to Waiting on
Author while I
FYI, the WIP patch does not seem to apply cleanly anymore using the latest HEAD.
See the cfbot rebase logs [1].
--
[1] http://cfbot.cputube.org/patch_42_4225.log
Kind Regards,
Peter Smith.
Fujitsu Australia
Hi,
> > Outside the scope of special TimescaleDB tables and the speculated
> > pg_partman old-style table migration, will this proposed new feature
> > have any other application? In other words, do you know if this
> > proposal will be of any benefit to the *normal* users who just have
> >
On Fri, Mar 31, 2023 at 3:17 PM Peter Smith wrote:
> OK, my understanding is that TimescaleDB uses some kind of
> quasi-partitioned/inherited tables (aka hypertables? [1]) internally,
> and your proposed WIP patch provides a set_logical_root() function
> which combines with the logical
On Wed, Mar 1, 2023 at 9:47 AM Jacob Champion wrote:
>
> Hi,
>
> I'm going to register this in CF for feedback.
>
> Summary for potential reviewers: we don't use declarative partitions in
> the Timescale partitioning scheme, but it'd be really nice to be able to
> replicate between our tables and
On Tue, Mar 7, 2023 at 2:40 AM Aleksander Alekseev
wrote:
> So far I only have a couple of nitpicks, mostly regarding the code coverage
> [1]:
Yeah, I need to work on error cases and their coverage in general.
There are more cases that I need to reject as well (marked TODO).
> +Datum
>
Hi Jacob,
> I'm going to register this in CF for feedback.
Many thanks for the updated patch.
Despite the fact that the patch is still work in progress all in all
it looks very good to me.
So far I only have a couple of nitpicks, mostly regarding the code coverage [1]:
```
+tablename =
Hi,
I'm going to register this in CF for feedback.
Summary for potential reviewers: we don't use declarative partitions in
the Timescale partitioning scheme, but it'd be really nice to be able to
replicate between our tables and standard tables, or between two
Timescale-partitioned tables with
On 1/10/23 11:36, Jacob Champion wrote:
> 1) I'm playing around with a marker in pg_inherits, where the inhseqno
> is set to a sentinel value (0) for an inheritance relationship that
> has been marked for logical publication. The intent is that the
> pg_inherits helpers will prevent further
On Mon, Jan 9, 2023 at 12:41 AM Aleksander Alekseev
wrote:
> I would like to point out that we shouldn't necessarily support
> multiple inheritance in all the possible cases, at least not in the
> first implementation. Supporting simple cases of inheritance would be
> already a valuable feature
Hi Jacob,
> we have to deal with multiple inheritance somehow
I would like to point out that we shouldn't necessarily support
multiple inheritance in all the possible cases, at least not in the
first implementation. Supporting simple cases of inheritance would be
already a valuable feature even
On Fri, Dec 9, 2022 at 10:21 AM Jacob Champion wrote:
> Some inheritance hierarchies won't be "partitioned" hierarchies, of
> course, but the user can simply not set that replication option for
> those publications.
The more I noodle around with this approach, the less I like it: it
feels overly
Hi,
TImescale makes use of inheritance in its partitioning implementation,
so we can't make use of the publish_via_partition_root publication
option during logical replication. We don't guarantee that the exact
same partitions exist on both sides, so that's a major roadblock for
our implementing
21 matches
Mail list logo
