Обсуждение: Re: [HACKERS] TODO Done. Superuser backend slot reservations

[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)
        - max_admin_connections denotes an additional # of backend
          slots that are reserved for connections from superusers. Not
          sure if this should default to zero or not
        - Therefore, the # of backend slots created is
          (max_connections + max_admin_connections)

> 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.

How can that happen?

+     /*
+      * Force ReservedBackends is less than MaxBackends if need be.
+      * A cluster only allowing superuser connections seems silly whereas
+      * a cluster reserving none for superusers doesn't.
+      */
+     if (ReservedBackends >= MaxBackends)
+         ReservedBackends = MaxBackends - 1;

IMHO, we should elog(FATAL) here, or at least emit a warning.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

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.

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.

--
  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 25 Aug 2002, Neil Conway wrote:

> [only replying to -patches, this doesn't belong on -hackers AFAICS ]

Is -patches for discussions? I thought it was only for the patches
themselves, I'd better go subscribe...

>
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> > 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.
>
> How can that happen?

Well, the test is located somewhere that is only called once, when the backend
process is forked. At least that's what I think but as I say I'm not 100%
certain, mostly becuase I haven't checked only looked to see what the
routine is doing and it looks like a one shot routine to me. Therefore,
assuming doing a SET SESSION AUTH... doesn't drop and then reconnect to the
server, a change from a superuser to a normaluser is not going to result in a
dropped connection. Nor should it do I believe.

>
> +     /*
> +      * Force ReservedBackends is less than MaxBackends if need be.
> +      * A cluster only allowing superuser connections seems silly whereas
> +      * a cluster reserving none for superusers doesn't.
> +      */
> +     if (ReservedBackends >= MaxBackends)
> +         ReservedBackends = MaxBackends - 1;
>
> IMHO, we should elog(FATAL) here, or at least emit a warning.

The warning sounds reasonable to me. I'll add one and resubmit in a day or two
after I've seen what else gets said.


--
Nigel J. Andrews

Neil Conway <neilc@samurai.com> writes:
>         - Therefore, the # of backend slots created is
>           (max_connections + max_admin_connections)

I tend to agree with Bruce on this: max_connections means
max_connections.  Therefore, the number of backend slots is
max_connections, of which max_connections - max_admin_connections
are available to non-superusers.

(There is provision in the existing code for one extra child process
for checkpoints, but it's not a "real" backend and so it's reasonable
not to count it against max_connections.)

            regards, tom lane

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