Re: pgbench internal contention
От | Tom Lane |
---|---|
Тема | Re: pgbench internal contention |
Дата | |
Msg-id | 3464.1312332249@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgbench internal contention (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pgbench internal contention
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> 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 both counts. We're going to end > up with the built-in erand48_r() on precisely those systems that use > glibc, and our own everywhere else. For the 25 SLOCs it's going cost > us, I'd rather use the same code everywhere. 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. 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 half an hour on that stupidity in an unrelated context... regards, tom lane
В списке pgsql-hackers по дате отправления: