Re: incorrect xlog.c coverage report
От | Thomas Munro |
---|---|
Тема | Re: incorrect xlog.c coverage report |
Дата | |
Msg-id | CAEepm=1ndDH0iOa0=dRtJuFJ088PXQSj8j6Wnqo5KBijg+7PyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: incorrect xlog.c coverage report (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: incorrect xlog.c coverage report
|
Список | pgsql-hackers |
On Thu, Nov 22, 2018 at 2:22 PM Michael Paquier <michael@paquier.xyz> wrote: > On Wed, Nov 21, 2018 at 01:20:48PM -0500, Tom Lane wrote: > > Alvaro Herrera <alvherre@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? 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. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: