Re: Threaded PosgreSQL server

On Thu, 7 Feb 2002, Haroldo Stenger wrote:

> 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.

Put this into context ... I had suggested someone submit'ng #ifdef'd code
that could implement threaded, not that someone submit'd code to clean up
a mess that nobody *really* wants to clean up due to time and lack of
visibility/glory *grin*

> > 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.

yes and no ... Tom is/was looking at it from an 'implement it for all the
systems we currently support' point of view, without looking at (and Tom,
feel free to correct me if I'm wrong) what has been implemented outside of
our project to simplify the portability and reliability issues associated
with supporting both a fork and fork/thread model ... with the work that
the Apache group has done in this regard, and the fact that their license
is not restrictive, both issues may (or may not) be moot, but someone has
to investigate that ...

In Peter's case ... I'm sorry, but I was always taught in programming that
"global variables should be avoided at all costs" ... right now, all I'm
advocating *right now* is making our variables thread safe, which, from my
understanding, means getting rid of the global variables ... not sure how
that affects the users themselves, but, from a programmers standpoint, the
'time' is what the person cleaning the code has to put into it ... once
its cleaned up, any new code or changes should just automatically be
"global variables aren't permitted"

Both Tom and Peter have better/more important things on their plates then
to go through the code and clean up the global variables ...

Eventually, I would like to see, where possible, threaded code put in so
that each connection is *still* forked, but parts of the connection that
could deal with more parralel processing making use of threads to speed it
up ...

> 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.

Correct, and that is what I am currently advocating ... if we get that
cleaned up, so that 'threaded' is possible, nothing stops the next step
being someone submit'ng a simple patch that uses threading to 'read from
disk while processing what has been read in, as it is being read in' ...
the point is, until we clean out the *time consuming, but relatively easy*
anti-thread issues we have, even if that is over several releases, nothing
else is going to happen cause "its too big of a job" ... what I would like
to see is someone submitting large patches that clean the global
variables, one global at a time ... I say large, because I would imagine
that pretty much any global is going to hit a *large* number of files to
remove it, and add it back in as an arg to functions ...

I can't see anyone convincingly argue against such patches, since, IMHO,
global variables are a remenent of when we took over the code from
Berkeley, I can't see any of the core developers actually *approving* of
them being there except the work involved in removing them ... :)