On Thu, Nov 22, 2018 at 10:43 AM Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > > On Thu, Nov 22, 2018 at 2:22 PM Michael Paquier <mich...@paquier.xyz> wrote: > > On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote: > > > Alvaro Herrera <alvhe...@2ndquadrant.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). > > So the issue is that quickdie() uses _exit(), so the GCOV atexit() > handler (or whatever similar mechanism they use for that) doesn't run, > right?
I think so too. Since gcov uses atexit(3) handler the exiting by exit(3) or from main() is required. > 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. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
