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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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