Re: [HACKERS] keeping track of connections

> 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.

On TODO list. Vadim wants to do this, perhaps for 6.4(not sure):

* Shared catalog cache, reduce lseek()'s by caching table size in shared area

>
> 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.

Then a good reason not to split them up.

> 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.

Yes, this would be nice, but don't we have more important items to the
TODO list to address?

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)