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-19T08:05:32Z
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 15:19, Amit Langote wrote:
> 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.

Committed with that change then.

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