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.1372352...@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-udc...@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.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to