Horton

Re: adding partitioned tables to publications

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-11-20T07:58:04Z
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 →

  1. Fix RELCACHE_FORCE_RELEASE issue

  2. Allow publishing partition changes via ancestors

  3. Add logical replication support to replicate into partitioned tables

  4. Refactor code to look up local replication tuple

  5. Some refactoring of logical/worker.c

  6. Prepare to support non-tables in publications

  7. Support adding partitioned tables to publication

On 2019-11-12 02:11, Amit Langote wrote:
>> I don't understand why you go through great lengths to ensure that the
>> relkinds match between publisher and subscriber.  We already ensure that
>> only regular tables are published and only regular tables are allowed as
>> subscription target.  In the future, we may want to allow further
>> combinations.  What situation are you trying to address here?
> I'd really want to see the requirement for relkinds to have to match
> go away, but as you can see, this patch doesn't modify enough of
> pgoutput.c and worker.c to make that possible.  Both the code for the
> initital syncing and that for the subsequent real-time replication
> assume that both source and target are regular tables.  So even if
> partitioned tables can now be in a publication, they're never sent in
> the protocol messages, only their leaf partitions are.  Initial
> syncing code can be easily modified to support any combination of
> source and target relations, but changes needed for real-time
> replication seem non-trivial.  Do you think we should do that before
> we can say partitioned tables support logical replication?

My question was more simply why you have this check:

+   /*
+    * Cannot replicate from a regular to a partitioned table or vice
+    * versa.
+    */
+   if (local_relkind != pt->relkind)
+       ereport(ERROR,
+               (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+                errmsg("cannot use relation \"%s.%s\" as logical 
replication target",
+                       rv->schemaname, rv->relname),

It doesn't seem necessary.  What happens if you remove it?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services