Re: Max backend limits cleaned up

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Max backend limits cleaned up
Дата
Msg-id 28740.919568875@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Max backend limits cleaned up  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: Max backend limits cleaned up  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
I did a little more work on the configurable-max-backends patch:

1. initdb didn't work because I had broken bootstrap mode :-(.
Fixed.

2. I separated the hard maximum limit on the number of backends
(MAXBACKENDS, used to size a couple of arrays) from the default
soft limit (now DEF_MAXBACKENDS).

3. The only cost of enlarging MAXBACKENDS is about 32 bytes per
array slot, so I set MAXBACKENDS at 1024 while leaving the
default DEF_MAXBACKENDS at 64.  (I more than bought back the 32K
by reducing the number of allocated spinlocks to what we were
actually using, anyway.)

4. Upshot: default limit on number of backends is 64, same as it
ever was, but you can set it as high as 1024 without a recompile.
Just start the postmaster with desired -N switch.  (Of course you
might need to reconfigure your kernel first ;-).)

5. Allocation of semaphores and shared memory is now based on
-N switch value (default or specified) rather than the MAXBACKENDS
constant.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Major bug, possible, with Solaris 7?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Re: Max backend limits cleaned up