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: Petr Jelinek <petr@2ndquadrant.com>, Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-08T05:45:54Z
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

Attachments

On Wed, Apr 8, 2020 at 1:22 AM Amit Langote <amitlangote09@gmail.com> wrote:
> On Tue, Apr 7, 2020 at 6:01 PM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
> > The descriptions of the new fields in RelationSyncEntry don't seem to
> > match the code accurately, or at least it's confusing.
> > replicate_as_relid is always filled in with an ancestor, even if
> > pubviaroot is not set.
>
> Given this confusion, I have changed how replicate_as_relid works so
> that it's now always set -- if different from the relation's own OID,
> the code for "publishing via root" kicks in in various places.
>
> > I think the pubviaroot field is actually not necessary.  We only need
> > replicate_as_relid.
>
> Looking through the code, I agree.  I guess I only kept it around to
> go with pubupdate, etc.

Think I broke truncate replication with this.  Fixed in the attached
updated patch.

--

Amit Langote
EnterpriseDB: http://www.enterprisedb.com