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

From Robert Haas
Subject Re: [HACKERS] Logical replication and inheritance
Date
Msg-id CA+TgmoZ7mVWxzdPoUp2S0riWZQAKxXbqc5T3K5ovLc++xqnqBQ@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Logical replication and inheritance  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] Logical replication and inheritance  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Wed, Apr 5, 2017 at 8:25 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> 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.

I think the threshold question here is: is the partitioned table a
member of the publication, or are the partitions members of the
publication?  Probably both should be allowed.  If you add a partition
to the publication by name, then we should publish exactly that
partition, full stop.  If you add the partitioned table, then there is
a choice of behaviors, including:

(1) That's an error; the user should publish the partitions instead.
(2) That's a shorthand for all partitions, resolved at the time the
table is added to the publication.  Later changes affect nothing.
(3) All partitions are published, and changes in the set of partitions
change what is published.

In my view, (3) is more desirable than (1) which is more desirable than (2).

> 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.

The latter approach sounds better to me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: [HACKERS] the need to finish
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] GCC 7 warnings