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: 2020-03-18T11:16:53Z
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 2020-03-18 04:06, Amit Langote wrote:
> +   if (isnull || !remote_is_publishable)
> +       ereport(ERROR,
> +               (errmsg("table \"%s.%s\" on the publisher is not publishable",
> +                       nspname, relname)));
> 
> Maybe add a one-line comment above this to say it's an "not supposed
> to happen" error or am I missing something?  Wouldn't elog() suffice
> for this?

On second thought, maybe we should just drop this check.  The list of 
tables that is part of the publication was already filtered by the 
publisher, so this query doesn't need to check it again.  We just need 
the relkind to be able to construct the COPY command, but we don't need 
to second-guess it beyond that.

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