|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>|
|Cc:||Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, kuroda(dot)hayato(at)fujitsu(dot)com|
|Subject:||Re: pgbench: option delaying queries till connections establishment?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
>> 3 . Decide if it's sane for the Windows-based emulation to be in here
>> too, or if it should stay in pgbench.c. Or alternatively, if we're
>> emulating pthread stuff on Windows, why not also put the other pthread
>> emulation stuff from pgbench.c into a "ports" file; that seems
>> premature and overkill for your project. I dunno.
> I decided to solve only the macOS problem for now. So in this
> version, the A and B patches are exactly as you had them in your v7,
> except that B includes “port/pg_pthread.h” instead of <pthread.h>.
> Maybe it’d make sense to move the Win32 pthread emulation stuff out of
> pgbench.c into src/port too (the pre-existing stuff, and the new
> barrier stuff you added), but that seems like a separate patch, one
> that I’m not best placed to write, and it’s not clear to me that we’ll
> want to be using pthread APIs as our main abstraction if/when thread
> usage increases in the PG source tree anyway. Other opinions welcome.
I think it would be much more consistent to move all the thread complement
stuff there directly: Currently (v8) the windows implementation is in
pgbench and the MacOS implementation in port, which is quite messy.
Attached is a patch set which does that. I cannot test it neither on
Windows nor on MacOS. Path 1 & 2 are really independent.
|Next Message||Thomas Munro||2021-01-30 12:52:43||Fix DROP TABLESPACE on Windows with ProcSignalBarrier?|
|Previous Message||Peter Eisentraut||2021-01-30 10:29:44||Re: SELECT INTO deprecation|