Re: Interrupts vs signals - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Interrupts vs signals
Date
Msg-id CA+Tgmoaneq02R54b-Tndd7pd08ntisiGGx8ZhucDj7Q8J+AeYg@mail.gmail.com
Whole thread Raw
In response to Re: Interrupts vs signals  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Interrupts vs signals
Re: Interrupts vs signals
List pgsql-hackers
On Wed, Jul 24, 2024 at 8:58 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> a) assign every child process a PGPROC entry, and make postmaster
> responsible for assigning them like you suggest. We'll need more PGPROC
> entries, because currently a process doesn't reserve one until
> authentication has happened. Or we change that behavior.

I wonder how this works right now. Is there something that limits the
number of authentication requests that can be in flight concurrently,
or is it completely uncapped (except by machine resources)?

My first thought when I read this was that it would be bad to have to
put a limit on something that's currently unlimited. But then I
started thinking that, even if it is currently unlimited, that might
be a bug rather than a feature. If you have hundreds of pending
authentication requests, that just means you're using a lot of machine
resources on something that doesn't really help anybody. A machine
with hundreds of authentication-pending connections is possibly
getting DDOS'd and probably getting buried. You'd be better off
focusing the machine's limited resources on the already-established
connections and a more limited number of new connection attempts. If
you accept so many connection attempts that you don't actually have
enough memory/CPU/kernel scheduling firepower to complete the
authentication process with any of them, it does nobody any good.

I'm not sure what's best to do here; just thinking out loud.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Dagfinn Ilmari Mannsåker
Date:
Subject: Re: CREATE MATERIALIZED VIEW
Next
From: Heikki Linnakangas
Date:
Subject: Re: Detect double-release of spinlock