pgsql: Fix bogus size calculation introduced by commit cc5f81366.

On Mon, Sep 18, 2017 at 3:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Fix bogus size calculation introduced by commit cc5f81366.

The elements of RecordCacheArray are TupleDesc, not TupleDesc *.
Those are actually the same size, so that this error is harmless,
but it's still wrong --- and it might bite us someday, if TupleDesc
ever became a struct, say.

Per Coverity.

Thanks.

While googling around trying to find where I could read Coverity's
output myself I was intrigued to see that https://scan.coverity.com
offers integration with Travis CI[1]https://scan.coverity.com/travis_ci, which suggests the possibility
of automatically scanning all Commitfest submissions. The trouble is
that for projects over 1 million lines of code they limit scans to one
per day, so it'd take over 200 days to get through the current
Commitfest, assuming no one ever posted new versions or committed
anything in the meantime. Hah. I guess Coverity analysis is going to
have to remain post-commit only.

[1]: https://scan.coverity.com/travis_ci

--
Thomas Munro
http://www.enterprisedb.com

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

On Mon, Sep 18, 2017 at 6:58 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:

While googling around trying to find where I could read Coverity's
output myself I was intrigued to see that https://scan.coverity.com
offers integration with Travis CI[1], which suggests the possibility
of automatically scanning all Commitfest submissions. The trouble is
that for projects over 1 million lines of code they limit scans to one
per day, so it'd take over 200 days to get through the current
Commitfest, assuming no one ever posted new versions or committed
anything in the meantime. Hah. I guess Coverity analysis is going to
have to remain post-commit only.

There are a mountain of false positives to take care of when doing the
initial scanning of a new project. So while the initial cost is high,
this would be maintainable in the long term if there is a continuous
effort put into it. The limit due to the project size sucks, but at
least this lets us know that coverity is not a solution for the CF.
Careful review is able to remove most of the problems anyway.
--
Michael

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers