Re: adding partitioned tables to publications

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: adding partitioned tables to publications
Дата
Msg-id CA+HiwqFWK3raKUU5Fp789jBsju-pYVpAiw0OsuO5sMX1CkYwFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: adding partitioned tables to publications  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: adding partitioned tables to publications  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Nov 12, 2019 at 10:11 AM Amit Langote <amitlangote09@gmail.com> wrote:
> Initial
> syncing code can be easily modified to support any combination of
> source and target relations, but changes needed for real-time
> replication seem non-trivial.

I have spent some time hacking on this.  With the attached updated
patch, adding a partitioned table to publication results in publishing
the inserts, updates, deletes of the table's leaf partitions as
inserts, updates, deletes of the table itself (it all happens inside
pgoutput).  So, the replication target table doesn't necessarily have
to be a partitioned table and even if it is partitioned its partitions
don't have to match one-to-one.

One restriction remains though: partitioned tables on a subscriber
can't accept updates and deletes, because we'd need to map those to
updates and deletes of their partitions, including handling a tuple
possibly moving from one partition to another during an update.

Also, I haven't added subscription tests yet.

Attached updated patch.  The previous division into a refactoring
patch and feature patch no longer made to sense to me, so there is
only one this time.

Thanks,
Amit

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: SegFault on 9.6.14
Следующее
От: Nicolas Lutic
Дата:
Сообщение: PITR on DROP DATABASE, deleting of the database directory despite therecovery_target_time set before.