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

From Peter Eisentraut
Subject Re: [HACKERS] Logical replication and inheritance
Date
Msg-id 8fe965d3-90e3-a1c6-0632-039b7abc8c4a@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] Logical replication and inheritance  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Logical replication and inheritance  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 4/9/17 22:16, Noah Misch wrote:
> On Wed, Apr 05, 2017 at 08:25:56AM -0400, Peter Eisentraut wrote:
>> After thinking about it some more, I think the behavior we want would be
>> that changes to inheritance would reflect in the publication membership.
>>  So if you have a partitioned table, adding more partitions over time
>> would automatically add them to the publication.
>>
>> We could implement this either by updating pg_publication_rel as
>> inheritance changes, or perhaps more easily by checking and expanding
>> inheritance in the output plugin/walsender.  There might be subtle
>> behavioral differences between those two approaches that we should think
>> through.  But I think one of these two should be done.
> 
> [Action required within three days.  This is a generic notification.]

Relative to some of the other open items I'm involved in, I consider
this a low priority, so I'm not working on it right now.  I would also
appreciate some guidance from those who are more involved in inheritance
and partitioning to determine the best behavior.  It could be argued
that the current behavior is correct, and also that there are several
other correct behaviors.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] snapbuild woes