Re: pgbench internal contention

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