Robert Haas wrote:
> Works for me. Just to confirm, that means we'd also change GEQO to
> use pg_erand48().
>
> > BTW, as far as the original plan of using random_r is concerned, how
> > did you manage to not run into this?
> > http://sourceware.org/bugzilla/show_bug.cgi?id=3662
> > I just wasted
Robert Haas writes:
> On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane wrote:
>> Maybe. But if that's the approach we want to use, let's just call it
>> pg_erand48 in the code, and dispense with the alias macros as well as
>> all vestiges of configure support.
> Works for me. Just to confirm, that mea
On Tue, Aug 2, 2011 at 8:44 PM, Tom Lane wrote:
> Robert Haas writes:
>>> If you want erand48_r, best to provide that API, not kluge up some
>>> other functions.
>
>> ...because erand48() is a GNU extension with a stupid API.
>
> I assume you mean erand48_r, there, because erand48 is pretty stand
Robert Haas writes:
>> If you want erand48_r, best to provide that API, not kluge up some
>> other functions.
> ...because erand48() is a GNU extension with a stupid API.
I assume you mean erand48_r, there, because erand48 is pretty standard.
> I don't
> see much value in supporting that, on bo
On Mon, Aug 1, 2011 at 11:33 AM, Tom Lane wrote:
>> Attached is a try at that approach.
>
> I don't find this to be a particularly safe idea:
>
>> #ifndef HAVE_ERAND48
>> -/* we assume all of these are present or missing together */
>> -extern double erand48(unsigned short xseed[3]);
>> -extern l
On 07/30/2011 09:08 AM, Robert Haas wrote:
If I'm reading the code right, it only modifies __libc_drand48_data on
first call, so as long as we called erand48() at least once before
spawning the child threads, it would probably work. That seems pretty
fragile in the face of the fact that they exp
Robert Haas writes:
> On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas wrote:
>> If I'm reading the code right, it only modifies __libc_drand48_data on
>> first call, so as long as we called erand48() at least once before
>> spawning the child threads, it would probably work. That seems pretty
>> fr
Robert Haas writes:
> If I'm reading the code right, it only modifies __libc_drand48_data on
> first call, so as long as we called erand48() at least once before
> spawning the child threads, it would probably work. That seems pretty
> fragile in the face of the fact that they explicitly state th
On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas wrote:
> If I'm reading the code right, it only modifies __libc_drand48_data on
> first call, so as long as we called erand48() at least once before
> spawning the child threads, it would probably work. That seems pretty
> fragile in the face of the fa
On Jul 30, 2011, at 9:40 AM, Andy Colson wrote:
> On 07/29/2011 04:00 PM, Robert Haas wrote:
>> On machines with lots of CPU cores, pgbench can start eating up a lot
>> of system time. Investigation reveals that the problem is with
>> random(), which glibc implements like this:
>>
>> long int
>>
On 07/29/2011 04:00 PM, Robert Haas wrote:
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(), which glibc implements like this:
long int
__random ()
{
int32_t retval;
__libc_lock_lock (lock);
(v
On Sat, Jul 30, 2011 at 2:32 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane wrote:
>>> Portability, or rather lack of it. What about using erand48, which we
>>> already have a dependency on (and substitute code for)?
>
>> Neither our implementation nor gl
Robert Haas writes:
> On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane wrote:
>> Portability, or rather lack of it. What about using erand48, which we
>> already have a dependency on (and substitute code for)?
> Neither our implementation nor glibc's appears to be thread-safe,
I think you're confusin
On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On machines with lots of CPU cores, pgbench can start eating up a lot
>> of system time. Investigation reveals that the problem is with
>> random(),
>
> Interesting.
>
>> I patched it to use random_r() - the patch is attac
Robert Haas writes:
> On machines with lots of CPU cores, pgbench can start eating up a lot
> of system time. Investigation reveals that the problem is with
> random(),
Interesting.
> I patched it to use random_r() - the patch is attached - and here are
> the (rather gratifying) results of that
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(), which glibc implements like this:
long int
__random ()
{
int32_t retval;
__libc_lock_lock (lock);
(void) __random_r (&unsafe_state, &retval);
__li
16 matches
Mail list logo
