Re: adding partitioned tables to publications - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: adding partitioned tables to publications
Date
Msg-id 44ecae53-9861-71b7-1d43-4658acc52519@2ndquadrant.com
Whole thread Raw
In response to Re: adding partitioned tables to publications  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: adding partitioned tables to publications  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: zombie connections
Next
From: Robert Haas
Date:
Subject: Re: zombie connections