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

Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Patrick Verdon <patrick(at)kan(dot)co(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Date: 1999-01-30 01:18:52
Message-ID: 199901300118.KAA00528@ext16.sra.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> MaxBackendId is 64 by default, so that's not the limit you're hitting.
> 
> It should be easier to configure MaxBackendId --- probably it should be
> an option to the configure script.  I've put this on my personal to-do
> list.  (I don't think it's a good idea to have *no* upper limit, even

Or even better, MaxBackendId can be set at the run time such as
postmaster's option. Also, it would be nice if we could monitor number
of backends currently running. Maybe we should have a new protocol for
this kind of puropose?

BTW, as I pointed out before, PostgreSQL will have serious problem
once hitting the MaxBackendId. My patches I proposed for this seem
still under discussion. I think we should solve the problem in the
next release in whatever way, however.
---
Tatsuo Ishii

pgsql-hackers by date

Next:From: Charles HornbergerDate: 1999-01-30 02:09:10
Subject: Re: [GENERAL] nested loops in joins, ambiguous rewrite rules
Previous:From: Hiroshi InoueDate: 1999-01-30 00:05:24
Subject: RE: [HACKERS] READ COMMITTED isolevel is implemented ...

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