Horton

Re: adding partitioned tables to publications

amit <amitlangote09@gmail.com>

View thread
From: Amit Langote <amitlangote09@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-18T14:19:01Z
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 Wed, Mar 18, 2020 at 8:16 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> 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.

Agreed.

-- 
Thank you,
Amit