Re: get_object_address support for additional object types - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: get_object_address support for additional object types
Date
Msg-id 20150316162621.GE3636@alvh.no-ip.org
Whole thread Raw
In response to Re: get_object_address support for additional object types  (Stephen Frost <sfrost@snowman.net>)
Responses Re: get_object_address support for additional object types
List pgsql-hackers
Stephen Frost wrote:
> Alvaro,
> 
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

> > Well, we already have make targets for gcov and friends; you get some
> > HTML charts and marked-up source lines with coverage counts, etc.  I
> > don't think we've made any use of that.  It'd be neat to have something
> > similar to our doxygen service, running some test suite and publishing
> > the reports on the web.  I remember trying to convince someone to set
> > that up for the community, but that seems to have yield no results.
> 
> I don't think we've made use of it either.  If the targets/code are
> already there to make it happen and it's just a matter of having a
> system running which is generating the website then I can probably get
> that going.  I was under the impression that there was more to it than
> that though.

"configure --enable-coverage"; install the resulting tree; then run
whatever tests you want, then "make coverage".  That's enough to get the
HTML reports.

> > We had someone else trying to submit patches to improve coverage of the
> > regression tests, but (probably due to wrong stars alignment) they
> > started with CREATE DATABASE which made the tests a lot slower, which
> > got the patches turned down -- the submitter disappeared after that
> > IIRC, probably discouraged by the lack of results.
> 
> Agreed, and I think that's unfortunate.  It's an area which we could
> really improve in and would be a good place for someone new to the
> community to be able to contribute- but we need to provide the right way
> for those tests to be added and that way isn't to include them in the
> main suite of tests which are run during development.

Well, I don't disagree that we could do with some tests that are run
additionally to the ones we currently have, but some basic stuff that
takes almost no time to run would be adequate to have in the basic
regression tests.  The one I'm thinking is something like generate a
VALUES of all the supported object types, then running
"pg_get_object_address" on them to make sure we support all object types
(or at least that we're aware which object types are not supported.)

For instance, Petr Jelinek's patch to add the TABLESAMPLE clause adds a
new object type which needs support in get_object_address, but I'm not
sure it's added to the stuff in the object_address test.  It's a very
easy omission to make.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reduce pinning in btree indexes
Next
From: Andrew Dunstan
Date:
Subject: Re: Allow "snapshot too old" error, to prevent bloat