Hello hackers,
This is take 2, I already suggested this 2 years ago...
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?
That would mean arguing that it is more important than a simpler code base
for pgbench, which would help both its maintenance and extension, and must
be kept despite these costs, hence the "strongly".
Tom's opinion, 2 years ago, was to object strongly:
http://www.postgresql.org/message-id/24846.1372352618@sss.pgh.pa.us
"I would object strongly to that, as it would represent a significant
movement of the goalposts on what is required to build Postgres at all, ie
platforms on which --enable-thread-safety is unavailable or expensive
would be out in the cold. Perhaps that set is approaching empty, but a
project that's still standardized on C89 has little business making such a
choice IMO."
However, about not providing a full feature under thread emulation:
"Perhaps that's worth doing. I agree with Fabien that full support of
this feature in the process model is more trouble than it's worth,
though, and I wouldn't scream loudly if we just didn't support it.
--disable-thread-safety doesn't have to be entirely penalty-free."
Robert Haas did also object strongly:
http://www.postgresql.org/message-id/CA+TgmoaJawAM0A4N1RnsndFhTOYYbwnt+7N7XWLcW=n-uDC79Q@mail.gmail.com
"I don't believe that to be an acceptable restriction. We generally
require features to work on all platforms we support. We have made
occasional compromises there, but generally only when the restriction is
fundamental to the platform rather than for developer convenience."
So the underlying question is, does Tom and Robert's opinion have changed
from 2 years ago?
If not, I would really like to know at least *one* current platform for
which --disable-thread-safety is required, just to know why I waste time
over such things.
--
Fabien.