Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
| От | Tatsuo Ishii |
|---|---|
| Тема | Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) |
| Дата | |
| Msg-id | 199901300118.KAA00528@ext16.sra.co.jp обсуждение |
| Ответ на | Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
|
| Список | 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 по дате отправления: