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 queryYou are
currentlyconnected 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