RE: [HACKERS] Re: Max backend limits cleaned up

Having recently experienced a similar problem with semaphores and
kernel size, I can say it is an issue. I feel that documentation
will clear it up either way. Either you lower the default backend
limit, and document how to raise it along with the associated kernel
variables, or leave it alone and document the appropriate steps to
tuning the kernel to accommodate it and how to lower it if you don't
want to tune the kernel.

DwD

> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)org]On Behalf Of Tom Lane
> Sent: Monday, February 22, 1999 10:10 AM
> To: Bruce Momjian
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [HACKERS] Re: Max backend limits cleaned up
>
>
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I am getting:
> > IpcSemaphoreCreate: semget failed (No space left on
> device) key=5432017,
> > num=16, permission=600
> > [ later ]
> > I got it working by adding a -N 32 to the postmaster
> startup. Looks
> > like my site BSD/OS can't start 64 backends. Some of
> my configuration
> > is wrong. Perhaps we need 32 as the default.
>
> Yeah, I was thinking about that myself. I left the
> default -N setting
> at 64 on the theory that people who had gone to the
> trouble of making
> sure they had proper kernel configurations should not get
> surprised by
> v6.5 suddenly reducing the default number-of-backends limit.
>
> On the other hand, we have reason to believe that a lot
> of systems are
> not configured to allow Postgres to grab 64 semaphores,
> so if we don't
> reduce the default -N value we will almost certainly see
> a lot of gripes
> just like the above when people move to 6.5. (I think -N
> 32 would work
> as a default on minimally-configured systems, but cannot
> prove it.)
>
> I haven't got a real strong feeling either way. Opinions?
>
> regards, tom lane
>