Thread: 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