On Tue, Apr 22, 2008 at 4:25 PM, Martijn van Oosterhout <kleptog@svana.org>
wrote:

> On Tue, Apr 22, 2008 at 10:31:53AM +0200, Zdenek Kotala wrote:
> > When you are able detect ordering difference you are able also check if
> it
> > is important for the test or not without any extra effort. Only what we
> > need is put some flag to test that order is not important.
>
> Not true. Sorting the file is going jumble all the results together.
> Since we perform many tests in one file, you're not going to be able to
> seperate them.
>
> > Regression test MUST BE bulletproof. If you get a error you must know
> that
> > it is really error (in postgresql or regtest) and must be fixed. When
> you
> > start to ignore some errors because it can happen sometimes you fall in
> the
> > trap soon.
>
> I think people are misunderstanding. You posted a bunch of diffs with
> that comment that they *appeared* to only be ordering differences. How
> good did you check? If an 8 become a 9 chances are you'd miss it.
> Having a second test checking the sorted results would at least
> preclude the chance that there really is something wrong.
>
> It was a guide, not a way of getting out of tests.
>

In the past, I had faced and tried to work on this exact problem... here's
what I had in mind:

in the .expected file, we would demarcate the section of lines we expect to
come in any order, by using two special markers. Then, when comparing the
actual output with expected output, we would take the demarcated group of
lines, and the corresponding lines from actual output, and compare them
after sorting.

For eg.

foo.expected:

select * from tenk where col1 <= 3 limit 3;

col1 | col2 | col3
-------------------------
?unsorted_result_start
1 | 10 | 100
2 | 20 | 200
3 | 30 | 300
?unsorted_result_end


foo.out:
select * from tenk where col1 <= 3 limit 3;

col1 | col2 | col3
-------------------------
3 | 30 | 300
2 | 20 | 200
1 | 10 | 100


So, the diff program should discard the lines beginning with '?' (meta
character), and then sort and match exactly the same number of lines.

There's another option of putting these '?' lines in a separate file
with corresponding begin/end line numbers of the unsorted group, and using
this as a parameter to the diffing program.

Of course, this needs a change in the (standard) diff that we use from
pg_regress!

Best regards,
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

Mail sent from my BlackLaptop device

Aaron Spiteri wrote:
>
>
> ------------------------------------------------------------------------
> I was wandering if there where any intentions of moving some of
> the currently internal numeric function prototypes to the Numeric
> header file. I believe such functions like cmp_numerics, add_var,
> etc would come in handy when writing user defined C code.
>
> Would there be many ill effects by doing this?
>
> What should I look out for if I try it?
>
>
> <http://mycareer.com.au/?s_cid=596065%20>

Umm ... you mean like this in builtins.h?

extern Datum numeric_cmp(PG_FUNCTION_ARGS);

cheers

andrew


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

"Aaron Spiteri" <azzmosphere@hotmail.com> writes:

> I was wandering if there where any intentions of moving some of the
> currently internal numeric function prototypes to the Numeric header file. I
> believe such functions like cmp_numerics, add_var, etc would come in handy
> when writing user defined C code.

All the var stuff is internal to the numeric data type operators. What kind of
user defined code are you writing?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

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

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Regression test MUST BE bulletproof.

I'm sorry, but this is not, never has been, and never will be an
iron-clad project rule. When you get a failure you are supposed
to inspect it to see if it's a problem.

regards, tom lane

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

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> By the way is any reason to have work_mem * 1024 "everywhere" when we have unit
> support in GUC?

Well, would you like to be able to set work_mem higher than 4GB on large
machines?

regards, tom lane

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

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Regression test MUST BE bulletproof.
>
> I'm sorry, but this is not, never has been, and never will be an
> iron-clad project rule. When you get a failure you are supposed
> to inspect it to see if it's a problem.

Yes, but when you find it you should fix or report a problem in postgresql or
regression test. Keep it untouched is not good idea. It is what I meant. Try to
look on Apache Derby unit/regression tests.

Zdenek



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

Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> By the way is any reason to have work_mem * 1024 "everywhere" when we have unit
>> support in GUC?
>
> Well, would you like to be able to set work_mem higher than 4GB on large
> machines?

I see, another int64 issues.

Thanks Zdenek

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

Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane napsal(a):
>> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>>> Regression test MUST BE bulletproof.
>>
>> I'm sorry, but this is not, never has been, and never will be an
>> iron-clad project rule. When you get a failure you are supposed
>> to inspect it to see if it's a problem.

> Yes, but when you find it you should fix or report a problem in postgresql or
> regression test. Keep it untouched is not good idea.

There are times when it's the most effective answer, though. I'm not
prepared to invest very large amounts of effort to fix corner-case
regression test problems, if those problems don't represent any actual
bug in the software. There are more productive ways to spend our time.
This is especially true if a proposed fix has negative consequences
beyond just the time to implement it --- reducing the scope of test
coverage or making the tests run longer would count as negative
consequences IMHO.

regards, tom lane

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

I wrote:
> Another possible answer is to change the minimum to be just 64K always.
> I'm not certain that it's really sensible to tie the minimum work_mem to
> BLCKSZ --- I don't think we do anything where work_mem is controlling a
> pool of page buffers, do we?

I've committed this change in HEAD. There's no desire to back-patch it
is there?

regards, tom lane

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

Tom Lane napsal(a):
> I wrote:
>> Another possible answer is to change the minimum to be just 64K always.
>> I'm not certain that it's really sensible to tie the minimum work_mem to
>> BLCKSZ --- I don't think we do anything where work_mem is controlling a
>> pool of page buffers, do we?
>
> I've committed this change in HEAD. There's no desire to back-patch it
> is there?

Back patch is not necessary. It is important for head, because
--with-blocksize=BLOCKSIZE allows to run buildfarm with different blocksize and
I think users will start to play more with this option.

Zdenek

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