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

Re: [HACKERS] postmaster failure with 2-23 snapshot

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: tih(at)nhh(dot)no, bpm(at)ec-group(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] postmaster failure with 2-23 snapshot
Date: 1999-02-25 17:36:51
Message-ID: 199902251736.MAA07505@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Tom Ivar Helbekkmo <tih(at)nhh(dot)no> writes:
> > Looking more closely into it, the postmaster is trying to allocate 64
> > semaphores in four groups of 16, so I built a new kernel with a higher
> > limit, and it's now OK.
> > This is as it should be, I hope?  It's not a case of something being
> > misconfigured now, using semaphores instead of some other facility?
> 
> Yes, this is an intentional change --- I guess you haven't been reading
> the hackers list very closely.  The postmaster is now set up to grab
> all the semaphores Postgres could need (for the specified number of
> backend processes) immediately at postmaster startup.  Failing then
> for lack of semaphores seems a better idea than failing under load
> when you try to start the N+1'st client, which is what used to happen.
> 
> There has been some discussion of reducing the default number-of-
> backends limit to 32 so that a stock installation is less likely
> to run out of semaphores.

Tom, better lower that limit soon.  People are having trouble with the
snapshots.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-hackers by date

Next:From: Terry MackintoshDate: 1999-02-25 17:39:10
Subject: Linux: semaphores: How?
Previous:From: Bruce MomjianDate: 1999-02-25 17:26:52
Subject: Re: [HACKERS] Current tree is busted

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