Re: getting rid of "thread fork emulation" in pgbench?

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> There is a "thread fork emulation" hack which allows pgbench to be
> compiled without threads by emulating them with forks, obviously with
> limited capabilities. This feature is triggered by configuring postgresql
> with --disable-thread-safety.

> I'm not aware of platforms which would still benefit from this feature (we
> are probably talking of a PostgreSQL 9.6 maybe released in 2016), and this
> thread emulation is a real pain for maintaining and extending it: some
> features cannot be implemented, or must be implemented twice, or must be
> implemented in a heavy way because it cannot be assumed to be in a
> threaded implementation.

> My question is: would someone still object strongly to the removal of this
> "thread fork emulation" hack in pgbench?

By my count, the pthread-emulation code amounts to about 175 lines out of
the nearly 4000 in pgbench.c. That's not an undue burden IMO (it's not,
for comparison's sake, very much more than the amount of WIN32-specific
code in that file). And what will you do instead? It would be fine
I think for pgbench to not allow --jobs different from 1 on a threadless
platform, but not for it to fail to work altogether. It looks to me like
allowing it to compile without that code would take nearly as much
effort/mess as what's there now.

> So the underlying question is, does Tom and Robert's opinion have changed
> from 2 years ago?

Not mine.

regards, tom lane