Re: 8.0.0 gmake check fails if on disk, passes on ram disk.... - Mailing list pgsql-bugs

From Jeff Ross
Subject Re: 8.0.0 gmake check fails if on disk, passes on ram disk....
Date
Msg-id 41F51C38.3000704@openvistas.net
Whole thread Raw
In response to Re: 8.0.0 gmake check fails if on disk, passes on ram disk....  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.0.0 gmake check fails if on disk, passes on ram disk....
List pgsql-bugs
Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
>
>>On Fri, Jan 21, 2005 at 05:03:08PM -0700, Jeff Ross wrote:
>>
>>>If I put the same source code up on a ram disk, configure and compile it
>>>the same way, all 96 tests pass.
>
>
>>Interesting.  Is this behavior consistent?  What's different 'twixt
>>the RAID disk and the RAM disk?
>
>
> If the problem is at bottom a too low processes-per-user limit, as it
> was for Jean-Gerard, then maybe the RAM-disk case passes because of
> different timing details.  This theory is a bit of a stretch though.
>
> In any case, we're being shown the wrong output.  What I want to know is
> what appears in the postmaster log when these failures happen?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>
>
I did a make clean, make, and gmake check this morning.  Fewer tests
failed (16 of the 96) on the raid1, and again no tests failed on the ram
disk.

Rather than post it in the e-mail, I've put the postmaster.log at

    http://www.openvistas.net/postmaster.log

Thanks!

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #1438: Non UTF-8 client encoding problem
Next
From: Tom Lane
Date:
Subject: Re: Privilege escalation via LOAD