Thread: TODO Done. Superuser backend slot reservations

TODO item:

Administration -
    Reserve last few process slots for super-user if max_connections
    reached


Notes:

Added GUC superuser_reserved_connections such that non-superuser connections
are only acceptable in the first
(max_connections - superuser_reserved_connections) backend slots.

Superuser connections within these first n slots count towards this
non-superuser connection limit. Therefore there can be at most this number
of non-superuser connections but may be less.

In addition, this limit is only checked on initialisation of a backend
process. So reserved slots can be taken by connections that subsequently
lose superuser priviledges thus evading the lower limit on backends.

Passed regression tests, not that it was likely not to.
Behaved as expected in a manual test.


--
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> +     if (!superuser() && MyBackendId > MaxBackends - ReservedBackends)
> +         elog(ERROR, "Normal user limit exceeded");

This coding is wrong on its face: the slot number you happen to find has
no relationship to the number of slots remaining free, except as an
existence proof that the number of slots free was > 0 before you took
one.

            regards, tom lane

On Mon, 26 Aug 2002, Tom Lane wrote:

> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > +     if (!superuser() && MyBackendId > MaxBackends - ReservedBackends)
> > +         elog(ERROR, "Normal user limit exceeded");
>
> This coding is wrong on its face: the slot number you happen to find has
> no relationship to the number of slots remaining free, except as an
> existence proof that the number of slots free was > 0 before you took
> one.

Yes.

I was taking the line that the last slots in the array are reserved. Those are
not going to be taken by non su connections. Therefore, if MyBackendId is
under the lower limit it doesn't matter if it's the only slot free since the
'safety' measure has already been used in restricting access to the last free
slots and it just so happens that those sessions are still active.

I take Neil's point about the order of the tests. That's my stupidity when
rearranging stuff after noticing in tests that the user information wasn't
available where I was [also stupidly] expecting it to be first time around.


--
Nigel J. Andrews

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> I was taking the line that the last slots in the array are
> reserved. Those are not going to be taken by non su connections.

But that doesn't do the job, does it?  My view of the feature is that
when there are at least MaxBackends - ReservedBackends slots in use (by
either su or non-su connections) then no new non-su jobs should be let
in.  For example, if the system is full (with a mix of su and non-su
jobs) and one non-su job quits, don't we want to hold that slot for a
possible su connection?

Your approach does have the advantage of being very cheap to test
(I think my semantics would require counting the active backends),
but I'm not sure that it really does what we want.

            regards, tom lane

Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > I was taking the line that the last slots in the array are
> > reserved. Those are not going to be taken by non su connections.
>
> But that doesn't do the job, does it?  My view of the feature is that
> when there are at least MaxBackends - ReservedBackends slots in use (by
> either su or non-su connections) then no new non-su jobs should be let
> in.  For example, if the system is full (with a mix of su and non-su
> jobs) and one non-su job quits, don't we want to hold that slot for a
> possible su connection?
>
> Your approach does have the advantage of being very cheap to test
> (I think my semantics would require counting the active backends),
> but I'm not sure that it really does what we want.

Tom is right.  If the last two slots are held by two long-running
super-user backends, and the slots fill, there will be no reserved
slots. The trick is that when the maximum number of backends is almost
exceeded, only let the supuer-user in.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 26 Aug 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > > I was taking the line that the last slots in the array are
> > > reserved. Those are not going to be taken by non su connections.
> >
> > But that doesn't do the job, does it?  My view of the feature is that
> > when there are at least MaxBackends - ReservedBackends slots in use (by
> > either su or non-su connections) then no new non-su jobs should be let
> > in.  For example, if the system is full (with a mix of su and non-su
> > jobs) and one non-su job quits, don't we want to hold that slot for a
> > possible su connection?
> >
> > Your approach does have the advantage of being very cheap to test
> > (I think my semantics would require counting the active backends),
> > but I'm not sure that it really does what we want.
>
> Tom is right.  If the last two slots are held by two long-running
> super-user backends, and the slots fill, there will be no reserved
> slots. The trick is that when the maximum number of backends is almost
> exceeded, only let the supuer-user in.

Okay, it's not how I was thinking as you know but I've got nothing against it
other than the backend slot scan time. I don't think that would be a
significant drain of cpu time so I'll implement that scheme and resubmit.

Got some other stuff to do first so it won't be done immediately but will in
the next day or so; in time for beta assuming it doesn't fall foul of any patch
review interval required.


--
Nigel J. Andrews