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
|
Список | 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 по дате отправления: