Horton

Re: adding partitioned tables to publications

amit <amitlangote09@gmail.com>

View thread
From: Amit Langote <amitlangote09@gmail.com>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Rafia Sabih <rafia.pghackers@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-04-04T14:43:44Z
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 Sat, Apr 4, 2020 at 5:56 PM Petr Jelinek <petr@2ndquadrant.com> wrote:
> On 04/04/2020 07:25, Tom Lane wrote:
> > Petr Jelinek <petr@2ndquadrant.com> writes:
> >> On 03/04/2020 17:51, Tom Lane wrote:
> >>> But the forked-off children have to write the gcov files independently,
> >>> don't they?
> >
> >> Hmm that's very good point. I did see these missing coverage issue when
> >> running tests that explicitly start more instances of postgres before
> >> though. And with some quick googling, parallel testing seems to be issue
> >> with gcov for more people.
> >
> > I poked around and found this:
> >
> > https://gcc.gnu.org/legacy-ml/gcc-help/2005-11/msg00074.html
> >
> > which says
> >
> >      gcov instrumentation is multi-process safe, but not multi-thread
> >      safe. The multi-processing safety relies on OS level file locking,
> >      which is not available on some systems.
> >
> > That would explain why it works for me, but then there's a question
> > of why it doesn't work for you ...
>
> Hmm, I wonder if it has something to do with docker then (I rarely run
> any tests directly on the main system nowadays). But that does not
> explain why it does not work for Amit either.

One thing to I must clarify: coverage for most of pgoutput.c looks
okay on each run.  I am concerned that the coverage for the code added
by the patch is shown to be close to zero, which is a mystery to me,
because I can confirm by other means such as debugging elogs() to next
to the new code that the newly added tests do cover them.

--
Thank you,

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