Re: RFC: logical publication via inheritance root?
От | Jacob Champion |
---|---|
Тема | Re: RFC: logical publication via inheritance root? |
Дата | |
Msg-id | f6478284-8556-6991-ee9d-ae4b72813f0e@timescale.com обсуждение исходный текст |
Ответ на | Re: RFC: logical publication via inheritance root? (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: RFC: logical publication via inheritance root?
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: