Re: adding partitioned tables to publications - Mailing list pgsql-hackers

From Amit Langote
Subject Re: adding partitioned tables to publications
Date
Msg-id CA+HiwqEgn5da9KvWP4y0rBjcMtHdRao01Lr6TgTw78+UGceJwQ@mail.gmail.com
Whole thread Raw
In response to Re: adding partitioned tables to publications  (Rafia Sabih <rafia.pghackers@gmail.com>)
Responses Re: adding partitioned tables to publications
Re: adding partitioned tables to publications
List pgsql-hackers
Hello Rafia,

Great to hear that you are interested in this feature and thanks for
testing the patch.

On Thu, Oct 10, 2019 at 10:13 PM Rafia Sabih <rafia.pghackers@gmail.com> wrote:
> Lately I was exploring logical replication feature of postgresql and I found this addition in the scope of feature
forpartitioned tables a useful one. 
>
> In order to understand the working of your patch a bit more, I performed an experiment wherein I created a
partitionedtable with several  children and a default partition at the publisher side and normal tables of the same
nameas parent, children, and default partition of the publisher side at the subscriber side. Next I established the
logicalreplication connection and to my surprise the data was successfully replicated from partitioned tables to normal
tablesand then this error filled the logs, 
> LOG:  logical replication table synchronization worker for subscription "my_subscription", table "parent" has started
> ERROR:  table "public.parent" not found on publisher
>
> here parent is the name of the partitioned table at the publisher side and it is present as normal table at
subscriberside as well. Which is understandable, it is trying to find a normal table of the same name but couldn't find
one,maybe it should not worry about that now also if not at replication time. 
>
> Please let me know if this is something expected because in my opinion this is not desirable, there should be some
checkto check the table type for replication. This wasn't important till now maybe because only normal tables were to
bereplicated, but with the extension of the scope of logical replication to more objects such checks would be helpful. 

Thanks for sharing this case.  I hadn't considered it, but you're
right that it should be handled sensibly.  I have fixed table sync
code to handle this case properly.  Could you please check your case
with the attached updated patch?

> On a separate note was thinking for partitioned tables, wouldn't it be cleaner to have something like you create only
partitiontable at the subscriber and then when logical replication starts it creates the child tables accordingly. Or
wouldthat be too much in future...? 

Hmm, we'd first need to built the "automatic partition creation"
feature to consider doing something like that.  I'm sure you'd agree
that we should undertake that project separately from this tiny
logical replication usability improvement project. :)

Thanks again.

Regards,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Next
From: Michael Paquier
Date:
Subject: Re: dropping column prevented due to inherited index