Re: [HACKERS] keeping track of connections

Поиск
Список
Период
Сортировка
От dg@illustra.com (David Gould)
Тема Re: [HACKERS] keeping track of connections
Дата
Msg-id 9806040329.AA02698@hawk.illustra.com
обсуждение исходный текст
Ответ на Re: [HACKERS] keeping track of connections  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
Marc G. Fournier writes:
> On Wed, 3 Jun 1998, Bruce Momjian wrote:
> >
> > Good question.  Postmaster does not have access to the system tables, so
> > it can't access them.  You could add a debug option to show it in the
> > server logs, or add it to the -d2 debug option that already shows SQL
> > statements.
>
> Here's one for you...and don't laugh at me, eh? :)
>
> postmaster starts up to listen for connections, and then starts up its own
> backend to handle database queries?  So, on a quiet system, you would have
> two processes running, one postmaster, and one postgres...
>
> basically, the idea is that postmaster can't talk to a table, only
> postgres can...so, setup postmaster the same way that any other interface
> is setup...connect to a backend and pass its transactions through that
> way...

Ok, can I laugh now?

Seriously, if we are going to have a separate backend to do the table access
(and I agree that this is both neccessary and reasonable), why not have it
be a plain ordinary backend like all the others and just connect to it from
the client? Why get the postmaster involved at all?

First, modifying the postmaster to add services has a couple of problems:

 - we have to modify the postmaster. This adds code bloat and bugs etc, and
   since the same binary is also the backend, it means the backends carry
   around extra baggage that only is used in the postmaster.

 - more importantly, if the postmaster is busy processing a big select from
   a pseudo table or log (well, forwarding results etc), then it cannot also
   respond to a new connection request. Unless we multithread the postmaster.


Second, it really isn't required to get the postmaster involved except in
maintaining its portion of the shared memory. Anyone that wants to do
status monitoring can connect in the normal way from a client to a backend
and query the pseudo-tables every second or however often they want. I
imagine an event log in a circular buffer could even be maintained in the
shared memory and made available as a pseudo-table for those who want that
sort of thing.

-dg


David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Don't worry about people stealing your ideas.  If your ideas are any
 good, you'll have to ram them down people's throats." -- Howard Aiken

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Brett W. McCoy"
Дата:
Сообщение: Re: [GENERAL] Re: [HACKERS] NEW POSTGRESQL LOGOS
Следующее
От: Kevin Heflin
Дата:
Сообщение: Re: [GENERAL] Re: [HACKERS] NEW POSTGRESQL LOGOS