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

Anyone understand shared-memory space usage?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Anyone understand shared-memory space usage?
Date: 1999-02-21 18:58:04
Message-ID: 1331.919623484@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
It used to be that Postgres' shared memory was sized on the basis of
the hard-wired MaxBackendId constant.  I have altered things so that
it is sized on the basis of the actual -N switch given to the postmaster
at postmaster start time.  This makes it a lot easier to stress the
algorithm ;-), and what I find is that it ain't too robust.

In particular, using current cvs sources try to start the postmaster
with "-N 1" (only one backend allowed).  The backend can be started
all right, but as soon as you try to do much of anything, it falls over:

$ startpg.debug -N 1
$ psql regression
Welcome to the POSTGRESQL interactive sql monitor:
  Please read the file COPYRIGHT for copyright terms of POSTGRESQL

   type \? for help on slash commands
   type \q to quit
   type \g or terminate with semicolon to execute query
 You are currently connected to the database: regression

regression=> \d
NOTICE:  ShmemAlloc: out of memory
pqReadData() -- backend closed the channel unexpectedly.


I conclude from this that the model of shared memory usage embodied
in LockShmemSize() (in src/backend/storage/lmgr/lock.c) isn't very
accurate: at small N it's not allocating enough memory.

Does anyone understand the data structures that are allocated in
shared memory well enough to fix LockShmemSize() properly?
Or should I just kluge it, say by making LockShmemSize() work from
something like MAX(maxBackends,10) ?

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1999-02-21 19:27:36
Subject: Re: [HACKERS] Re: Max backend limits cleaned up
Previous:From: Tom LaneDate: 1999-02-21 18:43:47
Subject: Re: [HACKERS] Re: Max backend limits cleaned up

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