Re: incorrect xlog.c coverage report

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

In response to

Responses

Browse pgsql-hackers by date

  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