From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: incorrect xlog.c coverage report |
Date: | 2018-11-22 02:15:17 |
Message-ID: | 20181122021517.GF3369@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 22, 2018 at 10:56:39AM +0900, Masahiko Sawada wrote:
> On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Presumably you could add your own call to __gcov_flush() in
>> quickdie(), so that we get GCOV data but no other atexit()-like stuff.
>> I see that some people advocate doing that in signal handlers, but I
>> don't know if it's really safe. If that is somehow magically OK,
>> you'd probably also need the chdir() hack from proc_exit() to get
>> per-pid files.
>
> That's probably a good idea, I'm also not sure if it's really safe
> though. An alternative approach could be that we can do $node->restart
> after recovered from $node->teardown_node() to write gcda file surely,
> although it would make the tests hard to read.
Thanks for looking at the details around that. I'd prefer much if we
have a solution like what's outline here because we should really try to
have coverage even for code paths which involve an immediate shutdown
(mainly for recovery). Manipulating the tests to get a better coverage
feels more like a band-aid solution, and does not help folks with custom
TAP tests in their plugins.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-11-22 02:32:04 | Re: Speeding up INSERTs and UPDATEs to partitioned tables |
Previous Message | Asim R P | 2018-11-22 02:12:04 | Re: Pluggable Storage - Andres's take |