| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Abhijit Menon-Sen <ams(at)toroid(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, 成之焕 <zhcheng(at)ceresdata(dot)com> |
| Subject: | Re: [PATCH] Exponential backoff for auth_delay |
| Date: | 2024-03-06 22:58:50 |
| Message-ID: | CAOYmi+k2jkTPeWxCvSi7qzAGLsckQyAyiuZcNjosNJpOBjjo2g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 6, 2024 at 2:45 PM Michael Banck <mbanck(at)gmx(dot)net> wrote:
> In order to at least make case 2 not worse for exponential backoff, we
> could maybe disable it (and just wait for auth_delay.milliseconds) once
> MAX_CONN_RECORDS is full. In addition, maybe MAX_CONN_RECORDS should be
> some fraction of max_connections, like 25%?
(Our mails crossed; hopefully I've addressed the other points.)
I think solutions for case 1 and case 2 are necessarily at odds under
the current design, if auth_delay relies on slot exhaustion to do its
work effectively. Weakening that on purpose doesn't make much sense to
me; if a DBA is uncomfortable with the DoS implications then I'd argue
they need a different solution. (Which we could theoretically
implement, but it's not my intention to sign you up for that. :D )
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2024-03-06 23:24:33 | Re: Stack overflow issue |
| Previous Message | Michael Paquier | 2024-03-06 22:54:51 | Re: Injection points: some tools to wait and wake |