Re: adding partitioned tables to publications
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-11-22T11:04:47Z
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
On Fri, Nov 22, 2019 at 4:16 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2019-11-22 07:28, Amit Langote wrote: > > >> What happens when you add a leaf table directly to a publication? Is it > >> replicated under its own identity or under its ancestor partitioned > >> table? (What if both the leaf table and a partitioned table are > >> publication members?) > > > > If both a leaf partition and an ancestor belong to the same > > publication, then leaf partition changes are replicated using the > > ancestor's schema. For a leaf partition to be replicated using its > > own schema it must be published via a separate publication that > > doesn't contain the ancestor. At least that's what the current patch > > does. > > Hmm, that seems confusing. This would mean that if you add a > partitioned table to a publication that already contains leaf tables, > the publication behavior of the leaf tables would change. So again, I > think this alternative behavior of publishing partitions under the name > of their root table should be an explicit option on a publication, and > then it should be ensured somehow that individual partitions are not > added to the publication in confusing ways. > Yeah, it can probably detect and throw an error for such cases. > So, it's up to you which aspect of this you want to tackle, but I > thought your original goal of being able to add partitioned tables to > publications and have that implicitly expand to all member partitions on > the publication side seemed quite useful, self-contained, and > uncontroversial. > +1. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com