Re: adding partitioned tables to publications
amit <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Rafia Sabih <rafia.pghackers@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-10-11T06:05:54Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix RELCACHE_FORCE_RELEASE issue
- 12fb189bfeaf 13.0 landed
-
Allow publishing partition changes via ancestors
- 83fd4532a721 13.0 landed
-
Add logical replication support to replicate into partitioned tables
- f1ac27bfda6c 13.0 landed
-
Refactor code to look up local replication tuple
- d8653f468789 13.0 landed
-
Some refactoring of logical/worker.c
- 97ee604d9bce 13.0 landed
-
Prepare to support non-tables in publications
- c314c147c056 13.0 landed
-
Support adding partitioned tables to publication
- 17b9e7f9fe23 13.0 landed
Attachments
- v2-0001-Support-adding-partitioned-tables-to-publication.patch (application/octet-stream) patch v2-0001
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 for partitioned tables a useful one. > > In order to understand the working of your patch a bit more, I performed an experiment wherein I created a partitioned table with several children and a default partition at the publisher side and normal tables of the same name as parent, children, and default partition of the publisher side at the subscriber side. Next I established the logical replication connection and to my surprise the data was successfully replicated from partitioned tables to normal tables and 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 subscriber side 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 check to check the table type for replication. This wasn't important till now maybe because only normal tables were to be replicated, 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 partition table at the subscriber and then when logical replication starts it creates the child tables accordingly. Or would that 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