From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: RFC: logical publication via inheritance root? |
Date: | 2023-01-20 17:53:28 |
Message-ID: | f6478284-8556-6991-ee9d-ae4b72813f0e@timescale.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
WIP-introduce-pg_set_logical_root-for-use-with-pubvi.patch | text/x-patch | 35.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-01-20 17:57:48 | Re: real/float example for testlibpq3 |
Previous Message | Ankit Kumar Pandey | 2023-01-20 17:32:13 | Re: [PATCH] Teach planner to further optimize sort in distinct |