Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group