RE: Stronger safeguard for archive recovery not to miss data - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Stronger safeguard for archive recovery not to miss data
Date
Msg-id TYAPR01MB29906108E3B59F7D63781898FE779@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Stronger safeguard for archive recovery not to miss data  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List 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 by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Stronger safeguard for archive recovery not to miss data
Next
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.