Re: [HACKERS] keeping track of connections

> On Wed, 3 June 1998, at 20:29:52, David Gould wrote:
>
> > 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?
>
> I'm confused, I guess.
> >
> > First, modifying the postmaster to add services has a couple of problems:
>
> I wasn't quite suggesting this, I think we should just modify the
> postmaster to store the information. As you say below, doing queries
> is probably bad, shared memory seems like the way to go. I'll assume
> we'll use a different block of shared memory than the one currently
> used.

Oh, ok. Some suggestions have been made the the postmaster would open a
connection to it's own backend to do queries. I was responding to this.
I agree that we should just store the information in shared memory.

> do you know how shared memory is currently used? I'm fairly clueless
> on this aspect.

The shared memory stores the process table, the lock table, the buffer cache,
and the shared invalidate list, and a couple of other minor things that all
the backends need to know about.

Strangely, the shared memory does not share a copy of the system catalog
cache. This seems like a real misfeature as the catalog data is very useful
to all the backends.

The shared memory is managed by its own allocator. It is not hard to carve
out a block for a new use, the only real trick is to make sure you account
for it when the system starts up so it can get the size right as the shared
memory is not extendable.

> > - 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.
>
> the reverse could also be said -- why does the postmaster need the
> bloat of a backend?

Well, right now the postmaster and the backend are the same binary. This
has the advantage of keeping them in sync as we make changes, and now with
Bruces patch we can avoid an exec() on backend startup. Illustra has a
separate backend and postmaster binary. This works too, but they share a
lot of code and sometimes a change in something you thought was only in the
backend will break 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.
> good point. I think storing this information in shared memory and
> accessing it from a view is good -- how do other dbs do this sort of
> thing?

Well, it is not really a view, although a view is a good analogy. The term
of art is pseudo-table. That is, a table you generate on the fly. This concept
is very useful as you can use it to read text files or rows from some other
database (think gateways) etc. It is also pretty common. Sybase and Informix
both support system specific pseudo-tables. Illustra supports extendable
access methods where you can plug a set of functions (opentable, getnext,
update, delete, insert etc) into the server and they create a table interface
to whatever datasource you want.

-dg

David Gould dg(at)illustra(dot)com 510.628.3783 or 510.305.9468
Informix Software 300 Lakeside Drive Oakland, CA 94612
- A child of five could understand this! Fetch me a child of five.