Re: pgbench: option delaying queries till connections establishment?

Hello Thomas,

>> I must say that I'm not a big fan of the macro-based all-in-capitals API
>> for threads because it exposes some platform specific uglyness (eg
>> THREAD_FUNC_CC) and it does not look much like clean C code when used. I
>> liked the previous partial pthread implementation better, even if it was
>> not the real thing, obviously.
>
> But we were using macros already, to support --disable-thread-safety
> builds.

Yep, but the look and feel was still C code.

> I just changed them to upper case and dropped the 'p', because I didn't
> like to pretend to do POSIX threads, but do it so badly.

Hmmm. From the source code point of view it was just like actually using
posix threads, even if the underlying machinery was not quite that on some
systems. I value looking at "beautiful" and "standard" code if possible,
even if there is some cheating involved, compared to exposing macros. I
made some effort to remove the pretty ugly and inefficient INSTR_TIME
macros from pgbench, replaced with straightforward arithmetic and inlined
functions. Now some other macros just crept back in:-) Anyway, this is
just "les goûts et les couleurs" (just a matter of taste), as we say here.

> Perhaps we should drop --disable-thread-safety soon, and perhaps it is
> nearly time to create a good thread abstraction in clean C code, for use
> in the server and here? Then we won't need any ugly macros.

+1.

>> ISTM that with the current approach threads are always used on Windows,
>> i.e. pgbench does not comply to "ENABLE_THREAD_SAFETY" configuration on
>> that platform. Not sure whether this is an issue that need to be
>> addressed, though.
>
> The idea of that option, as I understand it, is that in ancient times
> there were Unix systems with no threads (that's of course the reason
> PostgreSQL is the way it is). I don't think that was ever the case
> for Windows NT, and we have no build option for that on Windows
> AFAICS.

Ok, fine with me.

--
Fabien.