Re: RFC: logical publication via inheritance root? - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: RFC: logical publication via inheritance root?
Date
Msg-id f6478284-8556-6991-ee9d-ae4b72813f0e@timescale.com
Whole thread Raw
In response to Re: RFC: logical publication via inheritance root?  (Jacob Champion <jchampion@timescale.com>)
Responses Re: RFC: logical publication via inheritance root?
List pgsql-hackers
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 inheritance relationships
> when they see that marker, and reusing inhseqno means we can make use
> of the existing index to do the lookups. An example:
> 
>     =# CREATE TABLE root (a int);
>     =# CREATE TABLE root_p1 () INHERITS (root);
>     =# SELECT pg_set_logical_root('root_p1', 'root');
> 
> and then any data written to root_p1 gets replicated via root instead,
> if publish_via_partition_root = true. If root_p1 is set up with extra
> columns, they'll be omitted from replication.

First draft attached. (Due to some indentation changes, it's easiest to
read with --ignore-all-space.)

The overall strategy is
- introduce pg_set_logical_root, which sets the sentinel in pg_inherits,
- swap out any checks for partition parents with checks for logical
parents in the publishing code, and
- introduce the ability for a subscriber to perform an initial table
sync from multiple tables on the publisher.

> 2) While this strategy works well for ongoing replication, it's not
> enough to get the initial synchronization correct. The subscriber
> still does a COPY of the root table directly, missing out on all the
> logical descendant data. The publisher will have to tell the
> subscriber about the relationship somehow, and older subscriber
> versions won't understand how to use that (similar to how old
> subscribers can't correctly handle row filters).

I partially solved this by having the subscriber pull the logical
hierarchy from the publisher to figure out which tables to COPY. This
works when publish_via_partition_root=true, but it doesn't correctly
return to the previous behavior when the setting is false. I need to
check the publication setting from the subscriber, too, but that opens
up the question of what to do if two different publications conflict.

And while I go down that rabbit hole, I wanted to see if anyone thinks
this whole thing is unacceptable. :D

Thanks,
--Jacob
Attachment

pgsql-hackers by date:

Previous
From: Ankit Kumar Pandey
Date:
Subject: Re: [PATCH] Teach planner to further optimize sort in distinct
Next
From: Tom Lane
Date:
Subject: Re: real/float example for testlibpq3