Horton

Re: adding partitioned tables to publications

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Amit Langote <amitlangote09@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-03T15:51:45Z
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

Petr Jelinek <petr@2ndquadrant.com> writes:
> On 03/04/2020 16:59, Tom Lane wrote:
>> Petr Jelinek <petr@2ndquadrant.com> writes:
>>> 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).

>> Hm, really?  I routinely run "make check" (ie, parallel regression
>> tests) under coverage, and I get results that seem sane.  If I were
>> losing large chunks of the data, I think I'd have noticed.

> Parallel regression still just starts single postgres instance no?

But the forked-off children have to write the gcov files independently,
don't they?

			regards, tom lane