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
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.
On Apr 21, 2008, at 7:25 AM, Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I compiled postgreSQL with 1kB block size and regresion test
fails. Main
problem is that output is correct but in different order. See
attachment.
This was previously reported:
http://arch
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> Zdenek Kotala <[EMAIL PROTECTED]> 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 ins
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> 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
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> 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
Zdenek Kotala <[EMAIL PROTECTED]> 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-hacker
Zdenek Kotala <[EMAIL PROTECTED]> 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
--
On Tue, Apr 22, 2008 at 4:25 PM, Martijn van Oosterhout <[EMAIL PROTECTED]>
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 w
Martijn van Oosterhout napsal(a):
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 imp
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
Tom Lane napsal(a):
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?
Yeah, I try to find all usag
Andrew Dunstan napsal(a):
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatical
Peter Eisentraut napsal(a):
Am Montag, 21. April 2008 schrieb Tom Lane:
That sounds like a pretty bad idea, since it would treat ordering
differences as insignificant even when they aren't --- for example,
an ordering difference in the output of a query that *has* an
ORDER BY is usually a bug.
Am Montag, 21. April 2008 schrieb Tom Lane:
> That sounds like a pretty bad idea, since it would treat ordering
> differences as insignificant even when they aren't --- for example,
> an ordering difference in the output of a query that *has* an
> ORDER BY is usually a bug.
Well, we wouldn't treat
On Mon, Apr 21, 2008 at 10:54 PM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:
> Case 1.
>
> Insert 100 records --- goes into block 1 .. 10
> Delete 100 records
> Insert 100 more records --- goes into 11 .. 20
>
>
> Case 2.
>
> Insert 100 records --- goes into block 1 .. 10
> Delete 100 record
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Zdenek Kotala:
>> set work_mem = 64;
>> + ERROR: 64 is outside the valid range for parameter "work_mem" (256 ..
>> 2097151) -- Test bitmap-and.
> This should probably be fixed by using a unit specification on work_me
On Mon, Apr 21, 2008 at 8:20 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> No, the reason you don't see that is that plain VACUUM doesn't move
> tuples around.
>
I know. But plain VACUUM can free up dead space which can be used for
subsequent updates/inserts and that can cause reordering. For exa
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
>> I wonder if it would be feasable to, whenever a regression test fails
>> to sort both files and compare again. This should tell you if the
>> difference are *only* rearrangement automatically
Peter Eisentraut wrote:
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
I wonder if it would be feasable to, whenever a regression test fails
to sort both files and compare again. This should tell you if the
difference are *only* rearrangement automatically, without having to
eyeb
Am Montag, 21. April 2008 schrieb Martijn van Oosterhout:
> I wonder if it would be feasable to, whenever a regression test fails
> to sort both files and compare again. This should tell you if the
> difference are *only* rearrangement automatically, without having to
> eyeball the output.
That so
On Mon, Apr 21, 2008 at 02:25:31PM +0200, Peter Eisentraut wrote:
> > I think affected test should contain order by keyword.
>
> For previously established reasons, we don't want to add ORDER BY clauses to
> every test that might fail under exceptional circumstances so we test all
> plan types e
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I'm only testing behavior with different block size and I think it is not
> good idea to support only 8kB for regtest. When 4kB is used then PG fails
> in Join regresion test and with 16kB, 32kB it fails because:
>
> *** ./expected/bitmapops.out
Peter Eisentraut napsal(a):
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
I compiled postgreSQL with 1kB block size and regresion test fails. Main
problem is that output is correct but in different order. See attachment.
This was previously reported:
http://archives.postgresql.org/pgsql-ha
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Now that we have autovacuum on by default, we might get into random
> failures because of re-ordering. Though I don't seem to recall anybody
> complaining yet, it could just be that we are lucky or our regression
> suite don't have long enough running
On Mon, Apr 21, 2008 at 5:55 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>
> For previously established reasons, we don't want to add ORDER BY clauses to
> every test that might fail under exceptional circumstances so we test all
> plan types equally. I think very small block sizes are fai
Am Montag, 21. April 2008 schrieb Zdenek Kotala:
> I compiled postgreSQL with 1kB block size and regresion test fails. Main
> problem is that output is correct but in different order. See attachment.
This was previously reported:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg00901.php
I compiled postgreSQL with 1kB block size and regresion test fails. Main problem
is that output is correct but in different order. See attachment.
I think affected test should contain order by keyword.
Any comments?
Zdenek
*** ./expected/join.out Wed Jan 9 21:42:28 200
28 matches
Mail list logo
