Hi Tom,
I know what you're saying, but I've come across it multiple times.
The process for building a Solaris server for PostgreSQL is (from
memory) :
A) Install the OS
B) Install the latest Maintenance Update
C) Install the latest recommended patches
D) Adjust system values for semaphores and shared memory
E) Do an initial lockdown for system security
F) Reboot for the new settings to take effect
G) Create postgres group and postgres user
H) Compile postgres
I) Run the regression tests
J) Lockdown system again
K) Reboot, test startup scripts, etc
<etc>
If I'm working very late and can't find the semaphore settings, then
sometimes I'll do them out-of-order.
A number of times I've totally forgotten to change things until
PostgreSQL complains either in the regression tests (as described in
this thread) or during normal startup.
We're talking a few times anyway, probably about.... um... 15 - 20 times
or so that I've forgotten.
Regards and best wishes,
Justin Clift
Tom Lane wrote:
>
> Justin Clift <jclift@iprimus.com.au> writes:
> > If it's of any help, I get the same types of regression testing failures
> > on Solaris, with the same "is the backend running?" type error
> > messages.. when the installation of solaris HAS NOT had it's /etc/system
> > file altered to change the amount of shared memory segments and
> > semaphores.
>
> > Whenever I have those problems, I insert the updated (higher) values for
> > shared memory and semaphores, reboot the system, then the tests pass as
> > the backend is able to start fine.
>
> Hm. That's interesting, but it's fairly hard to believe. For at least
> a couple releases past, Postgres has grabbed all the shared memory and
> semaphores that it wants at postmaster start. Insufficient shmem/sema
> resources should result in postmaster abort, not in occasional failures
> to start backends.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
