Skip site navigation (1) Skip section navigation (2)

Re: pgbench internal contention

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench internal contention
Date: 2011-08-01 15:33:45
Message-ID: 25629.1312212825@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jul 30, 2011 at 9:08 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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 explicitly state that
>> they're modifying the global random generator state and that you
>> should use erand48_r() if you want reentrant behavior. So I think if
>> we're going to go the erand48() route we probably ought to force
>> pgbench to always use our version rather than any OS-supplied version.

> 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 long lrand48(void);
> -extern void srand48(long seed);
> +#define erand48(x) pg_erand48(x)
> +#define lrand48() pg_lrand48()
> +#define srand48(x) pg_srand48(x)
>  #endif

See our recent trials with python headers for an example of why this
might cause problems on some platforms.  For that matter, I believe
<stdlib.h> would be within its rights to be defining these names as
macros already.

If you want erand48_r, best to provide that API, not kluge up some
other functions.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-08-01 15:55:00
Subject: Re: One-Shot Plans
Previous:From: Tom LaneDate: 2011-08-01 15:26:59
Subject: Re: pgbench internal contention

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group