From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(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 01:21:53 |
Message-ID: | 20181122012153.GD3369@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
>> I think we should change all calls of ->teardown_node to ->stop(),
>> except the one in the END block, and look for places which are currently
>> relying too much on END (i.e. add more ->stop() calls where needed).
>
> Hm. We probably don't want to have zero coverage of immediate stop mode,
> though I agree we could cut it way back.
The root of the issue is that gcov is not able to write out the gcda
file when Postgres is stopped in immediate mode? There are some code
paths in the recovery tests where teardown_node is used on purpose (see
for example 009_twophase.pl).
At a lower level, teardown_node is actually just doing
$node->stop('immediate'). Would it be perhaps less confusing when
reading the tests to remove teardown_node and use $node->stop
everywhere, with the stop mode wanted? This needs a careful lookup
though. I am also wondering about the performance impact in the time it
takes to run the tests in serializable fashion. fsync is disabled so
the shutdown checkpoint would have less impact, still that's worth
checking.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-11-22 01:42:42 | Re: incorrect xlog.c coverage report |
Previous Message | Stephen Frost | 2018-11-22 01:12:19 | Re: Online verification of checksums |