Re: [HACKERS] Logical replication and inheritance - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] Logical replication and inheritance
Date
Msg-id df48c958-8b1f-ffad-636a-06818a4a6bf3@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Logical replication and inheritance  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: [HACKERS] Logical replication and inheritance  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] [BUG FIX] Removing NamedLWLockTrancheArray
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Logical replication and inheritance