RE: Stronger safeguard for archive recovery not to miss data
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Stronger safeguard for archive recovery not to miss data |
Дата | |
Msg-id | TYAPR01MB29906108E3B59F7D63781898FE779@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Stronger safeguard for archive recovery not to miss data (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com> > I didn't see that, but found the following article. > > https://stackoverflow.com/questions/2590794/gcov-warning-merge-mismat > ch-for-summaries ... > It seems like your working directory needs some cleanup. That could very well be. It'd be safer to run "make coverage-clean" between builds. I thought otherwise that the multiple TAP tests that were simultaneously run conflicted on the .gcda file. If this is thecase, we may not be able to eliminate the failure possibility. (make -J 1 circumvents this?) https://www.postgresql.org/docs/devel/install-procedure.html "If using GCC, all programs and libraries are compiled with code coverage testing instrumentation." 33.4. TAP Tests https://www.postgresql.org/docs/devel/regress-tap.html "Generically speaking, the TAP tests will test the executables in a previously-installed installation tree if you say makeinstallcheck, or will build a new local installation tree from current sources if you say make check. In either casethey will initialize a local instance (data directory) and transiently run a server in it. Some of these tests run morethan one server." "It's important to realize that the TAP tests will start test server(s) even when you say make installcheck; this is unlikethe traditional non-TAP testing infrastructure, which expects to use an already-running test server in that case. SomePostgreSQL subdirectories contain both traditional-style and TAP-style tests, meaning that make installcheck will producea mix of results from temporary servers and the already-running test server." Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: