Re: join regression failure on cygwin

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: join regression failure on cygwin
Date: 2009-07-24 14:27:54
Message-ID: 4A69C4EA.4000909@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> I wrote:
>
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>
>>> It appears on Googling a bit that the erand48() is buggy in that it
>>> requires the seed to have been initialized with srand48() or it will
>>> constantly return 0.0.
>>>
>
>
>> Huh, and that sends us into an infinite loop? I'll take a look at that.
>> Even though it's surely nonrandom, it doesn't seem like pathological
>> behavior of the RNG should wedge us completely.
>>
>
> The answer is that a constant RNG result sends this bit of
> geqo_selection() into a tight loop:
>
> int first,
> second;
>
> first = linear(root, pool->size, bias);
> second = linear(root, pool->size, bias);
>
> if (pool->size > 1)
> {
> while (first == second)
> second = linear(root, pool->size, bias);
> }
>
> Not sure if it's worth trying to do something about that, or exactly
> what we'd do anyway. Even if we hacked this up somehow, a constant RNG
> result would pretty much break GEQO for any useful purpose. So it could
> be argued that having the regression tests fail here is a good thing...
>
>
>

Right. Let's let sleeping dogs lie. I think at most a code comment is
the only action called for.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-07-24 14:47:06 Re: display previous query string of idle-in-transaction
Previous Message Tom Lane 2009-07-24 14:22:23 Re: join regression failure on cygwin