Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Threaded PosgreSQL server
Date
Msg-id 19835.1013121692@sss.pgh.pa.us
Whole thread Raw
In response to Re: Threaded PosgreSQL server  ("D. Hageman" <dhageman@dracken.com>)
Responses Re: Threaded PosgreSQL server  ("D. Hageman" <dhageman@dracken.com>)
List pgsql-hackers
"D. Hageman" <dhageman@dracken.com> writes:
> (Come on ... the first thing a programmer is 
> taught is that global variables are BAD).

Reality check time: I don't believe there are very many
gratuitously-static variables in the backend.  Most of the ones I can
think of offhand are associated with data structures that are actually
global, or at least would be of interest to more than one thread.
(For example, the catcache/relcache data structures are referenced from
static variables.  You would very likely want these caches to be shared
across as many threads as possible.  The data structures associated with
configuration variables would need to be shared by all threads executing
on behalf of a particular client connection.  Etc.)  So the hard part of
making the code "thread safe" is figuring out what we want to do with
potentially-sharable data structures: can they be shared, if so across
what scope, and what sort of locking penalty will we pay for sharing
them?

Maybe I'm missing something, but I don't think that a "coding practices"
document will do much of anything to improve our threading situation.
It might be worth having on other grounds, but not that one.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "D. Hageman"
Date:
Subject: Re: Threaded PosgreSQL server
Next
From: "D. Hageman"
Date:
Subject: Re: Threaded PosgreSQL server