Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

Here I'll respectfully compile the opinions that I found of impact over a
dicision:

Revisited key developer opinion 1:

Tom Lane wrote:
> > If someone wanted to submit appropriate patches for the v7.3 development
> > tree, that merge cleanly, I can't see why this wouldn't be a good thing
> 
> I would resist it.  I do not think we need the portability and
> reliability headaches that would come with it.  Furthermore,
> an #ifdef'd implementation would be the worst of all possible
> worlds, as it would do major damage to readability of the code.

Revisited key developer opinion 2:

Peter Eisentraut wrote:
> > Though, starting to think & code thread safe would be nice too.
> 
> The thing about thread-safeness is that it's only actually useful when
> you're using threads.  Otherwise it wastes everybody's time -- the
> programmer's, the computer's, and the user's.


So at least for Tom Lane and Peter E., threads are hard to implement. For Tom,
we would enter a world of portability and reliability headaches. For Peter,
unless we *want* threads, we don't have to start *now* coding thread safe.
Please correct me if I'm wrong.

Zeugswetter Andreas SB SD wrote:
> > If someone wanted to submit appropriate patches for the v7.3 development
> > tree, that merge cleanly, I can't see why this wouldn't be a good thing
> 
> I thought that the one thread instead of one process per client model
> would only be an advantage for the "native Windows port" ?
> 
> Imho a useful threaded model on unix would involve a separation of threads
> and clients. ( 1 CPU thread per physical CPU, several IO threads)
> But that would involve a complete redesign.

For Andreas, for a threaded PG to be useful under a Unix environment, a complete
PG redesign would be needed.


"Marc G. Fournier" wrote:
> 
> On Wed, 6 Feb 2002, Haroldo Stenger wrote:
> 
> > > Depends on how it is handled ...
> >
> > How do you see it not slowing down, when key developers said their view
> > is that multithreading will pose a major obstacle? Are you envisioning
> > any special approach not already talked about?
> 
> Read my previous emails?  To move *any part of PgSQL* to a threaded model
> (even one where each connection is still forked, but parts of each
> connection are threaded), the mess of global variables needs to be cleaned
> up ... that will be one of the "major obstacles" ... if someone with a
> knowledge of making code thread-safe were to submit patches (even very
> large ones) that start to clean this up, it could be broken down into more
> manageable chunks ...
> 

Yes, I liked too the idea of multiple process, running multiple threads each,
distributed under some wise criteria.

I wonder if cleaning up the mess of global variables, seems not convenient from
Peter's or Tom's point of view. Standard wisdom says globals should be avoided.
In current PG's case, they should be reworked in a way or another.

> The second major obstacle that has been identified is cross-platform
> comapability ... as I mentioned already, and another has also, Apache2 has
> their APR code that might help us reduce that obstacle to a more
> manageable level, since, I believe, the Apache license wouldn't restrict
> us to being able to use/distribute the code ... this is definitely
> something that we'd have to look into to make sure though ...

I agree with cross-polinization among open source projects. BTW, this practice
should be encouraged, and not called "stealing", not even as a joke, as I've
seen it called for example for the TCP/IP Linux stack code (99% sure this was
the one module), which came from the *BSD projects, in its very first version.
Also mentioning that BSD -> GPL was possible, but not the other way round; I
don't mean to start a war or anything, just exposing facts.

> The point is that nobody is even implying that this is a "for v7.3"
> project ... there have been several projects that have been initiated over
> the years that have straddled releases, and we have alot of very good
> developers, and testers, that will make sure that any changes are "for the
> good" ...

Yes, I agree. If starting to think & code thread safe *now* proves *not* to be a
waste of everybody's time, that's the path to follow. This very point is the one
under technical examination, right? 

Regards,
Haroldo.