Horton

Re: adding partitioned tables to publications

Petr Jelinek <petr@2ndquadrant.com>

View thread
From: Petr Jelinek <petr@2ndquadrant.com>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-03T14:43:17Z
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

Hi,

On 03/04/2020 16:25, Amit Langote wrote:
> On Fri, Apr 3, 2020 at 6:34 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> I am checking test coverage at the moment and should have the patches
>> ready by sometime later today.
> 
> Attached updated patches.
> 
> I confirmed using a coverage build that all the new code in
> logical/worker.c due to 0002 is now covered. For some reason, coverage
> report for pgoutput.c doesn't say the same thing for 0003's changes,
> although I doubt that result.  It seems strange to believe that *none*
> of the new code is tested.  I even checked by adding debugging elog()s
> next to the lines that the coverage report says aren't exercised,
> which tell me that that's not true. Perhaps my coverage build is
> somehow getting messed up, so it would be nice if someone with
> reliable coverage builds can confirm one way or the other. I will
> continue to check what's wrong.
> 

AFAIK gcov can't handle multiple instances of same process being started 
as it just overwrites the coverage files. So for TAP test it will report 
bogus info (as in some code that's executed will look as not executed). 
We'd probably have to do some kind of `GCOV_PREFIX` magic in the TAP 
framework and merge (gcov/lcov can do that AFAIK) the resulting files to 
get accurate coverage info. But that's beyond this patch IMHO.

-- 
Petr Jelinek
2ndQuadrant - PostgreSQL Solutions for the Enterprise
https://www.2ndQuadrant.com/