Re: Documentation improvements for partitioning

On 2017/02/27 3:18, Petr Jelinek wrote:
> On 24/02/17 07:15, Robert Haas wrote:
>> On Fri, Feb 24, 2017 at 9:53 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>> The good news is that logical replication DOES work with partitioning,
>>> but only for a Publication with PUBLISH INSERT, pushing from a normal
>>> table to a partitioned one. Which is useful enough for first release.
>>>
>>> The work on having UPDATE work between partitions can be used to make
>>> updates and deletes work in logical replication. That might yet be
>>> made to work in this release, and I think we should look into it, but
>>> I think it can be left til next release if we try.
>>
>> Are you speaking of the case where you want to replicate from an
>> unpartitioned table to a partitioned table? I would imagine that if
>> you are replicating between two identical partitioning hierarchies, it
>> would just work. (If not, that's probably a bug, though I don't know
>> whose bug.)
>>
>
> Yes same hierarchies will work but mainly because one has to add
> partitions themselves to publication currently. I guess that's the
> limitation we might have to live with in 10 as adding the whole
> partitioned table should probably work for different hierarchies when we
> enable it and I am not quite sure that's doable before start of the CF
> at this point.

If and when we add support to add partitioned tables to publications, I
think it will work by recursing to include the partitions to the same
publication (I see that OpenTableList() in publicationcmds.c calls
find_all_inheritors if recursion is requested by not specifying ONLY).
When a subscription replicates from this publication, it's going to match
changes for individual leaf partitions, not the root parent table. IOW,
none of the changes applied to a partitioned table are replicated as
changes to the table itself. So, it seems that adding a partitioned table
to a publication or subscription would simply be a *shorthand* for adding
all the (leaf) partitions that will actually emit and receive changes.
I'm not sure but should adding/removing partitions after the fact cause
their addition/removal from the publication (& subscription)? Maybe we'll
discuss these issues later.

By the way, we currently get the following error due to the relkind check
in check_publication_add_relation():

create publication p_pub for table p;
ERROR: "p" is not a table
DETAIL: Only tables can be added to publications.

Would it be better to produce an error message that explicitly states that
adding partitioned tables to publications is not supported. Something like:

create publication p_pub for table p;
ERROR: table "p" cannot be replicated
DETAIL: Adding partitioned tables to publications is not supported.

Thanks,
Amit