Re: [HACKERS] TODO Done. Superuser backend slot reservations

From: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] TODO Done. Superuser backend slot reservations
Date: 2002-08-26 22:58:00
Message-ID: Pine.LNX.4.21.0208262354370.667-100000@ponder.fairway2k.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, 26 Aug 2002, Bruce Momjian wrote:

> Tom Lane wrote:
> > "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-27 00:14:09 Re: Default privileges for new databases (was Re: Can't import large objects in most recent cvs)
Previous Message D'Arcy J.M. Cain 2002-08-26 22:04:04 MemoryContextAlloc: invalid request size 1934906735

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-08-27 03:04:59 Re: script to check consistency between guc.h and postgresql.conf.sample
Previous Message Tom Lane 2002-08-26 20:51:40 Re: revised patch for PL/PgSQL table functions