Re: [HACKERS] Logical replication and inheritance

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [HACKERS] Logical replication and inheritance
Дата
Msg-id df48c958-8b1f-ffad-636a-06818a4a6bf3@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Logical replication and inheritance  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] Logical replication and inheritance  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 2017/03/04 4:24, Peter Eisentraut wrote:
> On 2/27/17 01:57, Amit Langote wrote:
>> I see that if the table is a inheritance parent, and ONLY is not
>> specified, the child tables are also added to the publication.
> 
>> If the child table is later removed from the inheritance hierarchy, it
>> continues to be a part of the publication.
> 
>> Perhaps that's intentional?
> 
> I came across this the other day as well.  It's not clear what the best
> way for this to behave would be.  Another option would be to check the
> then-current inheritance relationships in the output plugin.

I thought removal of a table from inheritance hierarchy would delete it
from publications that its parents are part of.

One more option is for OpenTableList() called by CreatePublication() and
AlterPublicationTables() to not disregard inheritance, as if ONLY was
specified.

Related: I noticed that if you dump a database containing a publication
and an inheritance parent is published by it, loading that into another
database causes the following error for each child.

ERROR:  relation "bar" is already member of publication "foo_pub"

Because when foo, the parent, is added to foo_pub publication, bar (a
child of foo) is added implicitly.

Thanks,
Amit





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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Logical replication and inheritance