Hi Thomas,
> 1. I didn't have --enable-cassert enabled before. Oops.
> 2. It'll now dump a gdb backtrace for any core files found after a
> check-world failure (if you can find your way to the build log...).
> Thanks to Andres for the GDB scripting for this!
> 3. It'll now push gcov results to codecov.io -- see link at top of
> page. Thanks again to Andres for this idea.
> 4. It now builds a little bit faster due to -j4 (Travis CI VMs have 2
> virtual cores) and .proverc -j3. (So far one entry now fails in TAP
> tests with that setting, will wait longer before drawing any
> conclusions about that.)
Wow. Well done!
> LLVM sanitizer stuff
In my experience it doesn't work well with PostgreSQL code, way to many
false positives. For more details see this discussion [1].
> Valgrind
That would be great. Please note that Valgrind generates false reports
regarding memory leaks in PostgreSQL so you should use --leak-check=no.
Also USE_VALGRIND should be defined in src/include/pg_config_manual.h
before building PostgreSQL. Here [2] is a script I'm using.
> Coverity
I believe it would be not easy to integrate with the web-version of
Coverity. On the other hand Clang Static Analyzer often finds real
defects and it's very easy to integrate with it. Here is my script [3].
> more compilers, <your idea here>
In my experience trying to compile a patch on FreeBSD with Clang often
helps to find some sort of defect. Same regarding trying different
architectures, e.g. x64, x86, arm.
[1]: https://www.postgresql.org/message-id/20160321130850.6ed6f598%40fujitsu
[2]: https://github.com/afiskon/pgscripts/blob/master/valgrind.sh
[3]: https://github.com/afiskon/pgscripts/blob/master/static-analysis.sh
--
Best regards,
Aleksander Alekseev
