Re: [HACKERS] keeping track of connections

From: dg(at)illustra(dot)com (David Gould)
To: scrappy(at)hub(dot)org (The Hermit Hacker)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, brett(at)work(dot)chicken(dot)org, pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] keeping track of connections
Date: 1998-06-04 03:29:52
Message-ID: 9806040329.AA02698@hawk.illustra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)illustra(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Heflin 1998-06-04 03:32:13 Re: [GENERAL] Re: [HACKERS] NEW POSTGRESQL LOGOS
Previous Message David Gould 1998-06-04 03:18:11 Re: [HACKERS] Current sources?