Re: pgbench internal contention - Mailing list pgsql-hackers

From Greg Smith
Subject Re: pgbench internal contention
Date
Msg-id 4E3751BF.5080502@2ndQuadrant.com
Whole thread Raw
In response to Re: pgbench internal contention  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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 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.
>    

By the way:  the landmines in this whole area are what sunk the attempt 
to switch pgbench over to using 64 bits for the accounts table back in 
February.  See the last few messages of 
http://postgresql.1045698.n5.nabble.com/Re-PERFORM-pgbench-to-the-MAXINT-td3337374.html 
to revisit.  I think you've retraced all of that now, but double 
checking your plan against things like the AIX specific weirdness I 
pointed out there may be useful.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: libedit memory stomp is apparently fixed in OS X Lion
Next
From: Robert Haas
Date:
Subject: Re: [RFC] Common object property boards