On Sun, Jul 19, 2015 at 9:53 AM, Andres Freund wrote:
> Perhaps this could be moved into a virtual machine hosted by the
> postgres project infrastructure?
I would definitely be willing to start an external project to provide
additional coverage tests if I thought someone was inclined to run
them
On 2015-07-19 12:35:46 -0400, Peter Eisentraut wrote:
> I would like to do that, but the current host has no more capacity and
> the hoster is complaining, so I need to look for a new hosting solution
> before I can expand what is being built.
Perhaps this could be moved into a virtual machine hos
On 7/6/15 3:52 PM, Alvaro Herrera wrote:
> Kevin Grittner wrote:
>> Alvaro Herrera wrote:
>>> Peter Geoghegan wrote:
>>
It would be nice to always have a html report from gcov always
available on the internet. That would be something useful to
automate, IMV.
>>>
>>> http://pgci.eise
On Mon, Jul 6, 2015 at 12:52 PM, Alvaro Herrera
wrote:
> I suggest CC'ing Peter as a first measure. I already suggested this (or
> something similar) to him months ago.
This would be a worthwhile effort. tuplesort.c only has 46% coverage.
There is no coverage for functions that I know are used a
Kevin Grittner wrote:
> Alvaro Herrera wrote:
> > Peter Geoghegan wrote:
>
> >> It would be nice to always have a html report from gcov always
> >> available on the internet. That would be something useful to
> >> automate, IMV.
> >
> > http://pgci.eisentraut.org/jenkins/job/postgresql_master_cov
On Mon, Jul 6, 2015 at 12:27 PM, Kevin Grittner wrote:
> What would it take to get something like that which uses the
> check-world target instead of just the check target? Without the
> additional tests (like the isolation tests), some of these numbers
> don't reflect the coverage of regularly r
Alvaro Herrera wrote:
> Peter Geoghegan wrote:
>> It would be nice to always have a html report from gcov always
>> available on the internet. That would be something useful to
>> automate, IMV.
>
> http://pgci.eisentraut.org/jenkins/job/postgresql_master_coverage/Coverage/
What would it take to
Peter Geoghegan wrote:
> It would be nice to always have a html report from gcov always
> available on the internet. That would be something useful to automate,
> IMV.
http://pgci.eisentraut.org/jenkins/job/postgresql_master_coverage/Coverage/
--
Álvaro Herrerahttp://www.2ndQuad
On Wed, Jul 1, 2015 at 2:38 PM, Peter Geoghegan wrote:
> On Tue, Jun 30, 2015 at 10:35 PM, Peter Geoghegan wrote:
>> The regression tests have zero coverage for this
>> tuplesort_performsort() "btspool2" case. That's a fairly common case
>> to have no coverage for, and that took me all of 5 minut
On Tue, Jun 30, 2015 at 10:35 PM, Peter Geoghegan wrote:
> The regression tests have zero coverage for this
> tuplesort_performsort() "btspool2" case. That's a fairly common case
> to have no coverage for, and that took me all of 5 minutes to find.
BTW, I looked here because I added a bunch of so
On Tue, Jun 30, 2015 at 10:25 PM, Peter Geoghegan wrote:
> It would be nice to always have a html report from gcov always
> available on the internet. That would be something useful to automate,
> IMV. Watching that regress over time might provide useful insight, but
> I only use gcov a couple of
On Tue, Jun 30, 2015 at 9:39 PM, Michael Paquier
wrote:
>> There is no real testing of sorting in the regression tests. It would
>> be nice to have a way of generating a large and varied selection of
>> sort operations programmatically, to catch this kind of thing.
>> pg_regress is not really up t
On Wed, Jul 1, 2015 at 9:36 AM, Peter Geoghegan wrote:
> On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby wrote:
>> Isn't this the kind of thing Coverty's supposed to find?
>
> I don't know, but in general I'm not very excited about static
> analysis tools. The best things that they have going for them
On Tue, Jun 30, 2015 at 5:25 PM, Jim Nasby wrote:
> Isn't this the kind of thing Coverty's supposed to find?
I don't know, but in general I'm not very excited about static
analysis tools. The best things that they have going for them is that
they're available, and don't require test coverage in t
On 6/29/15 6:47 PM, Peter Geoghegan wrote:
As we all know, the state of automated testing is pretty lamentable.
This is the kind of thing that we could catch more easily in the
future if better infrastructure were in place. I caught this by
eyeballing bttext_abbrev_convert() with slightly fresher
On Mon, Jun 29, 2015 at 7:47 PM, Peter Geoghegan wrote:
> Commits b181a919 and arguably c79b6413 added bugs to
> bttext_abbrev_convert() in the process of fixing some others. In the
> master branch, bttext_abbrev_convert() can leak memory when the C
> locale happens to be used and we must detoast,
Commits b181a919 and arguably c79b6413 added bugs to
bttext_abbrev_convert() in the process of fixing some others. In the
master branch, bttext_abbrev_convert() can leak memory when the C
locale happens to be used and we must detoast, which is unacceptable
for about the same reason that it's unacce
17 matches
Mail list logo
