Re: Logical replication and inheritance

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical replication and inheritance
Date: 2017-04-12 15:02:44
Message-ID: 8fe965d3-90e3-a1c6-0632-039b7abc8c4a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-04-12 15:03:57 Re: snapbuild woes
Previous Message Andreas Karlsson 2017-04-12 15:00:06 Re: Cutting initdb's runtime (Perl question embedded)