On Mon, Jan 16, 2023 at 09:06:10PM -0500, Robert Haas wrote:
> On Mon, Jan 16, 2023 at 5:37 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
>> On Mon, Jan 16, 2023 at 02:29:56PM -0500, Robert Haas wrote:
>> > 4. You can reserve a small number of connections for the superuser
>> > with superuser_reserved_connections, but there's no way to do a
>> > similar thing for any other user. As mentioned above, a CREATEROLE
>> > user could set connection limits for every created role such that the
>> > sum of those limits is less than max_connections by some margin, but
>> > that restricts each of those roles individually, not all of them in
>> > the aggregate. Maybe we could address this by inventing a new GUC
>> > reserved_connections and a predefined role
>> > pg_use_reserved_connections.
>>
>> I've written something like this before, and I'd be happy to put together a
>> patch if there is interest.
>
> Cool. I had been thinking of coding it up myself, but you doing it works, too.
Alright. The one design question I have is whether this should be a new
set of reserved connections or replace superuser_reserved_connections
entirely.
If we create a new batch of reserved connections, only roles with
privileges of pg_use_reserved_connections would be able to connect if the
number of remaining slots is greater than superuser_reserved_connections
but less than or equal to superuser_reserved_connections +
reserved_connections. Only superusers would be able to connect if the
number of remaining slots is less than or equal to
superuser_reserved_connections. This helps avoid blocking new superuser
connections even if you've reserved some connections for non-superusers.
Іf we replace superuser_reserved_connections, we're basically opening up
the existing functionality to non-superusers, which is simpler and probably
more in the spirit of this thread, but it doesn't provide a way to prevent
blocking new superuser connections.
My preference is the former approach. This is closest to what I've written
before, and if I read your words carefully, it seems to be what you are
proposing. WDYT?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
