On Sun, 25 Aug 2002, Bruce Momjian wrote:
> Neil Conway wrote:
> > [only replying to -patches, this doesn't belong on -hackers AFAICS ]
> >
> > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > > Added GUC superuser_reserved_connections such that non-superuser connections
> > > are only acceptable in the first
> > > (max_connections - superuser_reserved_connections) backend slots.
> >
> > I'd prefer that we not change the meaning of max_connections. I had in
> > mind the following:
> >
> > - max_connections denotes the # of "regular" connections to
> > the database (i.e. admin & non-admin)
>
> Well, if you do that, then max_connections is really not max
> connections, it is maximum connections minus admin_connections. That
> seems confusing.
That was my thinking. Plus, MaxBackends gets used in quite a few places, to
avoid having to go to extremes and look at and possibly hit each of those
places to ensure things are correct seems silly. An alternative would be to
change the variable max_connections is tied to and make MaxBackends the
sum of two GUCs. I couldn't see the point in doing either of those when
max_connections should define the maximum number of connections possible
and not something less.
Hmmm...rereading that it strikes me that we're all reading from the same
page of the same book. All three of us are saying max_connections gives
the maximum number of connections possible from admin and non-admin users
together.
> I think I prefer just reserving 1-2 of the last slots. The kernel's
> proc code is the same; if you specify a proc table of 150, it is 150,
> with 149 and 150 reserved for root.
Yes, only the exact number reserved at the top of the slot array is
configurable via the GUC variable.
--
Nigel J. Andrews