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?  (Jacob Champion <jchampion@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Ankit Kumar Pandey
Дата:
Сообщение: Re: [PATCH] Teach planner to further optimize sort in distinct
Следующее
От: Tom Lane
Дата:
Сообщение: Re: real/float example for testlibpq3