Re: [HACKERS] keeping track of connections

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: dg(at)illustra(dot)com (David Gould)
Cc: brett(at)work(dot)chicken(dot)org, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] keeping track of connections
Date: 1998-06-05 20:56:21
Message-ID: 199806052056.QAA11889@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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(at)candle(dot)pha(dot)pa(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Olivier 1998-06-05 23:13:34 dfas
Previous Message Vince Vielhaber 1998-06-05 16:56:53 Re: [HACKERS] CGI with lilbpq