Per request from Qingqing, here is the version of pgbench I made up to
drive each backend from a separately forked subprocess. This is not
meant for application, at least not yet, since it won't work on Windows,
and there are performance issues to be resolved anyway. (If we figure
out the perform
Argh, I'm an idiot ... a big part of the problem with the original
fork-based pgbench is that I'd rearranged the startup code without
noticing a data dependency. You can't initialize the default scripts
until you've gotten the correct value of "tps" by inspecting the
database. What was happening
On Thu, 1 Dec 2005, Tom Lane wrote:
> Argh, I'm an idiot ... a big part of the problem with the original
> fork-based pgbench is that I'd rearranged the startup code without
> noticing a data dependency. You can't initialize the default scripts
> until you've gotten the correct value of "tps" b
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>
> I've threaded it in Win32 ...
>
Another thing is that if unix does fork() and windows does _beginthread(),
then there will be some potential problem. For example, you have to be
careful to add global variables ...
Regards,
Qingqing
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Qingqing Zhou" <[EMAIL PROTECTED]> wrote
>> I've threaded it in Win32 ...
> Another thing is that if unix does fork() and windows does _beginthread(),
> then there will be some potential problem. For example, you have to be
> careful to add global v
