Re: [HACKERS] keeping track of connections - Mailing list pgsql-hackers

From dg@illustra.com (David Gould)
Subject Re: [HACKERS] keeping track of connections
Date
Msg-id 9806040329.AA02698@hawk.illustra.com
Whole thread Raw
In response to Re: [HACKERS] keeping track of connections  (The Hermit Hacker <scrappy@hub.org>)
List 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 by date:

Previous
From: "Brett W. McCoy"
Date:
Subject: Re: [GENERAL] Re: [HACKERS] NEW POSTGRESQL LOGOS
Next
From: Kevin Heflin
Date:
Subject: Re: [GENERAL] Re: [HACKERS] NEW POSTGRESQL LOGOS