Re: Threaded PosgreSQL server

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "D(dot) Hageman" <dhageman(at)dracken(dot)com>
Cc: mlw <markw(at)mohawksoft(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, Haroldo Stenger <hstenger(at)adinet(dot)com(dot)uy>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Threaded PosgreSQL server
Date: 2002-02-07 22:41:32
Message-ID: 19835.1013121692@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D. Hageman" <dhageman(at)dracken(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D. Hageman 2002-02-07 23:31:03 Re: Threaded PosgreSQL server
Previous Message F Harvell 2002-02-07 22:35:43 Re: Replication