Re: gcov coverage data not full with immediate stop - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: gcov coverage data not full with immediate stop
Date
Msg-id 20200513074319.GP88791@paquier.xyz
Whole thread Raw
In response to Re: gcov coverage data not full with immediate stop  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On Mon, May 11, 2020 at 05:56:33PM +0530, Ashutosh Bapat wrote:
> What happens if a coverage tool other than gcov is used? From that
> perspective, it's better to perform a clean shutdown in the TAP tests
> instead of immediate if that's possible.

Nope, as that's the fastest path we have to shut down any remaining
nodes at the end of a test per the END{} block at the end of
PostgresNode.pm, and I would rather keep it this way because people
tend to like keeping around a lot of clusters alive at the end of any
new test added and shutdown checkpoints are not free either even if
fsync is enforced to off in the tests.

I think that a solution turning around __gcov_flush() could be the
best deal we have, as discussed last year in the thread Álvaro quoted
upthread, and I would vote for waiting until v14 opens for business
before merging something we consider worth it.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: No core file generated after PostgresNode->start
Next
From: Michael Paquier
Date:
Subject: Re: Event trigger code comment duplication