Manfred,
> Can't this be done on postmaster startup? I think of two GUC
> variables where there is only one today: min_shared_buffers and
> max_shared_buffers. If allocation for the max_ values fails, the
> numbers are decreased in a loop of, say, 10 steps until allocation
> succeeds, or even fa
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> The attached patch shows how initdb can dynamically determine reasonable
>> shared_buffers and max_connections settings that will work on the
>> current machine.
> Can't this b
On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>The attached patch shows how initdb can dynamically determine reasonable
>shared_buffers and max_connections settings that will work on the
>current machine.
Can't this be done on postmaster startup? I think of two GUC
varia
On Friday 04 July 2003 13:31, Michael Meskes wrote:
> On Fri, Jul 04, 2003 at 03:29:37PM -0400, Tom Lane wrote:
> > 2. If so, can I get away with applying this post-feature-freeze? I can
> > argue that it's a bug fix, but perhaps some will disagree.
>
> I'd say it is a bug fix.
>
> Michael
I'm wi
On Fri, Jul 04, 2003 at 03:29:37PM -0400, Tom Lane wrote:
> 2. If so, can I get away with applying this post-feature-freeze? I can
> argue that it's a bug fix, but perhaps some will disagree.
I'd say it is a bug fix.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304,
The attached patch shows how initdb can dynamically determine reasonable
shared_buffers and max_connections settings that will work on the
current machine. It consists of two trivial adjustments: one rips out
the "PrivateMemory" code, so that a standalone backend will allocate a
shared memory segm
