On Sun, Jul 7, 2013 at 10:35 AM, Robins Tharakan wrote:
> On 26 June 2013 01:55, Robins Tharakan wrote:
>>
>> Code coverage improved from 36% to 68%.
>
> Updated patch:
> - Renamed ROLEs as per Robert's feedback (prepend regress_xxx)
> - Added test to serial_schedule (missed out earlier).
Databa
On 26 June 2013 01:55, Robins Tharakan wrote:
>
> Code coverage improved from 36% to 68%.
>
Updated patch:
- Renamed ROLEs as per Robert's feedback (prepend regress_xxx)
- Added test to serial_schedule (missed out earlier).
--
Robins Tharakan
regress_db_v5.patch
Description: Binary data
--
Hi Andres,
Just an aside, your point about CONNECTION LIMIT was something that just
didn't come to my mind and is probably a good way to test ALTER DATABASE
with CONNECTION LIMIT.
Its just that that actually wasn't what I was testing there. That
'CONNECTION LIMIT' test was coupled with CREATE DAT
Peter Eisentraut wrote:
> On 6/27/13 10:20 AM, Robert Haas wrote:
>> So I'd like to endorse Josh's idea: subject to appropriate review,
>> let's add these test cases. Then, if it really turns out to be too
>> burdensome, we can take them out, or figure out a sensible way to
>> split the suit
On 6/27/13 10:57 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 6/26/13 12:17 PM, Tom Lane wrote:
>>> (I like to
>>> point at mysql's regression tests, which take well over an hour even on
>>> fast machines. If lots of tests are so helpful, why is their bug rate
>>> no better than ours?)
>
Peter Eisentraut writes:
> On 6/26/13 12:17 PM, Tom Lane wrote:
>> (I like to
>> point at mysql's regression tests, which take well over an hour even on
>> fast machines. If lots of tests are so helpful, why is their bug rate
>> no better than ours?)
> Tests are not (primarily) there to prevent
On 6/26/13 12:17 PM, Tom Lane wrote:
> (I like to
> point at mysql's regression tests, which take well over an hour even on
> fast machines. If lots of tests are so helpful, why is their bug rate
> no better than ours?)
Tests are not (primarily) there to prevent bugs.
--
Sent via pgsql-hacker
On 6/27/13 10:20 AM, Robert Haas wrote:
> So I'd like to endorse Josh's idea: subject to appropriate review,
> let's add these test cases. Then, if it really turns out to be too
> burdensome, we can take them out, or figure out a sensible way to
> split the suite. Pushing all of Robins work into
On Wed, Jun 26, 2013 at 11:33 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/26/2013 12:08 PM, Fabien COELHO wrote:
>>> I have been suggesting something upon that line in some of the reviews
>>> I've posted about Robins non regression tests, if they were to be
>>> rejected on the basis that t
Josh Berkus writes:
> On 06/26/2013 12:08 PM, Fabien COELHO wrote:
>> I have been suggesting something upon that line in some of the reviews
>> I've posted about Robins non regression tests, if they were to be
>> rejected on the basis that they add a few seconds for checks. They are
>> well made t
On 06/26/2013 12:08 PM, Fabien COELHO wrote:
> I have been suggesting something upon that line in some of the reviews
> I've posted about Robins non regression tests, if they were to be
> rejected on the basis that they add a few seconds for checks. They are
> well made to test corner cases quite s
I was intending to suggest that much of what Robins has submitted
doesn't belong in the core regression tests, but could usefully be put
into an optional set of "big" regression tests. We already have a
"numeric_big" test in that spirit. What seems to be lacking is an
organizational principle
Andres Freund writes:
> I am generally a bit unsure whether the regression tests you propose
> aren't a bit too verbose. Does any of the committers have an opinion
> about this?
> My feeling is that they are ok if they aren't slowing down things much.
Yeah, I'm concerned about speed too. If the
Hi,
I am generally a bit unsure whether the regression tests you propose
aren't a bit too verbose. Does any of the committers have an opinion
about this?
My feeling is that they are ok if they aren't slowing down things much.
On 2013-06-26 01:55:53 -0500, Robins Tharakan wrote:
> The CREATE DATA
Hi Andres,
Attached is a patch which
does not CREATE DATABASE, but now the regression tests do not test the
following:
- ALTER DATABASE RENAME TO is not allowed on a database in use. Had to
remove two tests that were using this.
- ALTER DATABASE SET TABLESPACE is also not allowed on a database i
On 2013-05-21 02:58:25 +0530, Robins Tharakan wrote:
> Attached is an updated patch that does only 1 CREATE DATABASE and reuses
> that for all other tests.
> The code-coverage with this patch goes up from 36% to 70%.
Even creating one database seems superfluous. The plain CREATE DATABASE
has been
Hi,
Attached is an updated patch that does only 1 CREATE DATABASE and reuses
that for all other tests.
The code-coverage with this patch goes up from 36% to 70%.
--
Robins Tharakan
On 13 May 2013 21:04, Robins Tharakan wrote:
> I believe Tom / Andres and Fabien all have valid points.
>
> Net-
Would try to revert with a faster script (preferably with minimal
CREATE/DROP).
Yes. I just checked with a few create database/drop database. One cycle
takes about 1 full second on my laptop, so I must agree that it is slow.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers
As for the cost, if the proposed tests are indeed too costly, what is not
necessarily the case for what I have seen, I do not think that it would be a
great problem to have two set of tests, with one a superset of the other,
with some convention.
Well, tests like permission tests aren't the ex
I believe Tom / Andres and Fabien all have valid points.
Net-net, I believe the tests although non-negotiable, are not required to
be in make-check. For now, its the slow tests that are the pain points
here, and then I would soon try to prune them and commit once again.
Whether it goes in make-ch
On 2013-05-13 16:52:08 +0200, Fabien COELHO wrote:
>
> Hello,
>
> >>Would you be okay if there is one/a few effective create/drop (some tests
> >>check that the create or drop fails e.g. depending on permissions, which
> >>ISTM is not tested anywhere else), so that tests for various ALTER
> >>DAT
Hello,
Would you be okay if there is one/a few effective create/drop (some tests
check that the create or drop fails e.g. depending on permissions, which
ISTM is not tested anywhere else), so that tests for various ALTER
DATABASE commands are combined together onto these databases?
TBH, I do
Fabien COELHO writes:
> Would you be okay if there is one/a few effective create/drop (some tests
> check that the create or drop fails e.g. depending on permissions, which
> ISTM is not tested anywhere else), so that tests for various ALTER
> DATABASE commands are combined together onto these
Please find attached a patch to take code-coverage of DBCommands (CREATE
DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
I wish to object strenuously to adding any more CREATE/DROP DATABASE
commands to the core regression tests. Those are at least one order of
magnitude more expen
Robins Tharakan writes:
> Please find attached a patch to take code-coverage of DBCommands (CREATE
> DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
I wish to object strenuously to adding any more CREATE/DROP DATABASE
commands to the core regression tests. Those are at least one orde
Hi,
Please find attached a patch to take code-coverage of DBCommands (CREATE
DATABASE / ALTER DATABASE / DROP DATABASE) from 36% to 71%.
Any and all feedback is obviously welcome.
--
Robins Tharakan
regress_db_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-ha
26 matches
Mail list logo
