> Again, if we go at it as 'threaded for v7.3', then most probably ... but I
> would not allow that to happen, nor would any of the *core* developers ...
> what I am, and have been, advocating is starting down the 'thread-safe'
> path ... as has actually been discussed before, there are sections of
> PostgreSQL that could make use of threading without the whole system
> *being* threaded ... stuff that, right now, are done sequentially that
> could be done in parralel if threading was available ...
How about doing what Marc suggests and start moving toward reentrant
functions in postgres.
This could be done by creating a global private
memory area that is accessed much like shared memory is now with a hash
table setting aside memory for various code subsections. We could put
all the global variables there with little impact on current functionality
and, if done right, speed. I think I have a good idea as to where most of
the "difficult" globals are and could start working on moving them once
the global memory area was set up. We can worry about threads vs.
processes later.
comments?
Myron