On 2018-Nov-22, Michael Paquier wrote: > 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.mu...@enterprisedb.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.
I've just realized that we didn't do anything about this (see line 5380 in https://coverage.postgresql.org/src/backend/access/transam/xlog.c.gcov.html) , and we should. I still prefer the solution I proposed (which is to edit the test files to avoid immediate shutdown in certain places), but I admit that adding __gcov_flush() to quickdie() seems to have gotten more votes. Are there objections to doing that now on the master branch? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
