Re: pgbench: option delaying queries till connections establishment?

On Wed, Mar 3, 2021 at 6:23 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sun, Jan 31, 2021 at 1:18 AM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> > 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.
>
> Hmm. Well this is totally subjective, but here's how I see this after
> thinking about it a bit more: macOS does actually have POSIX threads,
> except for this tiny missing piece, so it's OK to write a toy
> implementation that is reasonably conformant, and put it in there
> using the usual AC_REPLACE_FUNCS machinery. It will go away when
> Apple eventually adds a real one. Windows does not, and here we're
> writing a very partial toy implementation that is far from conformant.
> I think that's OK for pgbench's purposes, for now, but I'd prefer to
> keep it inside pgbench.c. I think at some point in the (hopefully not
> too distant) future, we'll start working on thread support for the
> backend, and then I think we'll probably come up with our own
> abstraction over Windows and POSIX threads, rather than trying to use
> POSIX API wrappers from Windows, so I don't really want this stuff in
> the port library. Does this make some kind of sense?

Here is an attempt to move things in that direction. It compiles
tests OK on Unix including macOS with and without
--disable-thread-safety, and it compiles on Windows (via CI) but I
don't yet know if it works there.

v10-0001-Add-missing-pthread_barrier_t.patch

Same as v8. Adds the missing pthread_barrier_t support for macOS
only. Based on the traditional configure symbol probe for now. It's
possible that we'll later decide to use declarations to be more
future-proof against Apple's API versioning strategy, but I don't have
one of those weird cross-version compiler setups to investigate that
(see complaints from James Hilliard about the way we deal with
pwrite()).

v10-0002-pgbench-Refactor-the-way-we-do-thread-portabilit.patch

New. Abandons the concept of doing a fake pthread API on Windows in
pgbench.c, in favour of a couple of tiny local macros that abstract
over POSIX, Windows and threadless builds. This results in less code,
and also fixes some minor problems I spotted in pre-existing code:
it's not OK to use (pthread_t) 0 as a special value, or to compare
pthread_t values with ==, or to assume that pthread APIs set errno.

v10-0003-pgbench-Improve-time-measurement-code.patch

Your original A patch, rebased over the above. I haven't reviewed
this one. It lacks a commit message.

v10-0004-pgbench-Synchronize-client-threads.patch

Adds in the barriers.