[Django] #33497: Database persistent connection do not work with ASGI in 4.0
Django
-----------------------------------------+--------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 4.0
Severity: Normal | Keywords: ASGI; Database
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+--------------------------------
Hello!
I've discovered that after upgrading Django to ver. 4 (currently 4.0.2), I
started to see database **FATAL: sorry, too many clients already** errors
in the Sentry.
For a database, I'm using containerized Postgres 14.1 and the connection
between Django and Postgres is done by Unix socket.
Database settings look like this:
{{{
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": environ.get("POSTGRES_DB"),
"USER": environ.get("POSTGRES_USER"),
"PASSWORD": environ.get("POSTGRES_PASSWORD"),
"HOST": environ.get("POSTGRES_HOST"),
"PORT": environ.get("POSTGRES_PORT"),
"CONN_MAX_AGE": 3600
}
}
}}}
In production, I'm using ASGI (Uvicorn 0.17.4) to run the Django
application (4 workers).
When everything is deployed and I have surfed around the Django admin
site, then checking Postgres active connections, using **SELECT * FROM
pg_stat_activity;** command, I see that there are 30+ Idle connections
made from Django.
After surfing more around the admin site, I can see that more Idle
connections have been made by Django.
It looks like the database connections are not reused. At one point some
of the Idle connections are closed, but then again more connections have
been made when more DB queries are made by Django.
I have one Django 3.2.11 project running on production and all the
settings are the same, there are always max 10 persistent connections with
the database and everything works fine.
Should that be like this in version 4.0?
--
Ticket URL: <https://code.djangoproject.com/ticket/33497>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI; Database | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Stenkar):
* component: Uncategorized => Database layer (models, ORM)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 4.0
(models, ORM) |
Keywords: ASGI; Database | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* cc: Carlton Gibson (added)
* status: new => closed
* resolution: => needsinfo
Comment:
Thanks for the report. Django has a
[https://github.com/django/django/blob/f0480ddd2d3cb04b784cf7ea697f792b45c689cc/django/db/__init__.py#L34-L42
routine] to clean up old connections that is tied into the request-
response life-cycle, so idle connections should be closed. However, I
don't think you've explained the issue in enough detail to confirm a bug
in Django. This can be an issue in `psycopg2`, `uvicorn`, or in custom
middlewares (see #31905) it's hard to say without a reproduce.
Please reopen the ticket if you can debug your issue and provide details
about why and where Django is at fault, or if provide a sample project
with reproducible scenario.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* cc: Florian Apolloner, Andrew Godwin (added)
Comment:
Hi Stenkar.
Would you be able to put together a minimal test-project here, so that
folks can reproduce quickly.
This **may** be due to Django 4.0 having per-request contexts for the
thread sensitivity of `sync_to_async()` — See #32889.
If so, that's kind-of a good thing, in that too many open resources is
what you'd expect in async code, and up to now, we've not been hitting
that, as we've essentially been running serially.
Immediate thought for a mitigation would be to use a connection pool.
Equally, can we limit the number of threads in play using
[https://github.com/django/asgiref/blob/02fecb6046bb5ec0dbbad00ffcd2043e893fcea5/asgiref/sync.py#L303-L304
asgiref's `AGSI_THREADS` environment variable]? (But see
[https://github.com/django/daphne/issues/319#issuecomment-991962381 the
discussion on the related Daphne issue about whether that's the right
place for that at all].)
This is likely a topic we'll need to deal with (eventually) in Django:
once you start getting async working, you soon hit resource limits, and
handling that with structures for sequencing and maximum parallelism is
one of those hard-batteries™ that we maybe should provide. 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution: needsinfo
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Florian Apolloner):
I think https://github.com/django/asgiref/pull/306#issuecomment-991959863
might play into this as well. By using a single thread per connection,
persistent connections will never get clean up.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: Bug | Status: new
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Stenkar):
* status: closed => new
* resolution: needsinfo =>
Comment:
Thank you for the comments.
I created a project where it's possible to spin up a minimal project with
docker-compose.
https://github.com/KStenK/django-ticket-33497
I'm not sure that I can find where or what goes wrong in more detail, but
I'll give it a try.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:6>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* type: Bug => New feature
* stage: Unreviewed => Accepted
Comment:
OK, thanks Stenkar.
I'm going to accept this as a New Feature. It's a change in behaviour from
3.2, but it's precisely in allowing multiple executors for
`sync_to_async()` that it comes up. (In 3.2 it's essentially single-
threaded, with only a single connection actually being used.) We need to
improve the story here, but it's not a bug in #32889 that we don't have
async compatible persistent DB connections yet. (I hope that makes sense.)
A note to the docs about this limitation may be worthwhile.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Florian Apolloner):
Thinking more about this I do not think the problem is new. We have the
same problem when persistent connections are used and a new thread is
generated per request (for instance in runserver.py). Usually (ie with
gunicorn etc) one has a rather "stable" pool of processes or requests; as
soon as you switch to new threads per connection this will break. In ASGI
this behavior is probably more pronounced since by definition every
request is in it's own async task context which then propagates down to
the db backend as new connection per request (which in turn will also
never reuse connections because the "thread" ids change).
All in all I think we are finally at the point where we need a connection
pool in Django. I'd strongly recommend to use something like
https://github.com/psycopg/psycopg/tree/master/psycopg_pool/psycopg_pool
but abstracted to work for all databases in Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:8>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Anders Kaseorg):
* cc: Anders Kaseorg (added)
Comment:
Possibly related: #33625 (for memcached connections).
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Patryk Zawadzki):
* cc: Patryk Zawadzki (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mikail):
* cc: Mikail (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Patryk Zawadzki):
This is marked as a "new feature," but it's an undocumented breaking
change between 3.2 and 4.0. Connections that were previously reused and
terminated are now just left to linger.
The {{{request_finished}}} signal does not terminate them as they are not
idle for longer than {{{MAX_CONN_AGE}}}.
The {{{request_started}}} signal does not terminate them as it never sees
those connections due to the connection state being {{{asgiref.local}}}
and discarded after every request.
Allowing parallel execution of requests is a great change, but I feel
Django should outright refuse to start if {{{MAX_CONN_AGE}}} is combined
with ASGI.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* keywords: ASGI; Database => ASGI, Database, async
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Alex):
* cc: Alex (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by joeli):
Replying to [comment:12 Patryk Zawadzki]:
> This is marked as a "new feature," but it's an undocumented breaking
change between 3.2 and 4.0. Connections that were previously reused and
terminated are now just left to linger.
>
> The {{{request_finished}}} signal does not terminate them as they are
not idle for longer than {{{MAX_CONN_AGE}}}.
>
> The {{{request_started}}} signal does not terminate them as it never
sees those connections due to the connection state being
{{{asgiref.local}}} and discarded after every request.
>
> Allowing parallel execution of requests is a great change, but I feel
Django should outright refuse to start if {{{MAX_CONN_AGE}}} is combined
with ASGI.
I agree. I would even go as far as calling this a regression, not just an
undocumented breaking change. No matter the reasons behind it or the
technical superiority of the new solution, fact of the matter stands that
in 3.2 ASGI mode our code worked fine and reused connections. In 4.x it is
broken unless using {{{MAX_CONN_AGE = 0}}}, which disables a feature in
Django that used to work.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by joeli):
* cc: joeli (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Marco Glauser):
* cc: Marco Glauser (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:17>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner:
| rajdesai24
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by rajdesai24):
* owner: nobody => rajdesai24
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by rajdesai24):
* owner: rajdesai24 => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:19>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Rafał Pitoń):
* cc: Rafał Pitoń (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Marty Cochrane):
* cc: Marty Cochrane (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:19>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Florian Apolloner):
I have created a draft pull request for database connection pool support
in postgresql: https://github.com/django/django/pull/16881
It would be great if people experiencing the problems noted here could
test this (this would probably help in getting it merged).
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:20>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by lappu):
* cc: lappu (added)
Comment:
We just ran into this while upgrading from 3.2 to 4.2. During a QA round
our staging environment '''MySQL''' server running on AWS RDS t3.micro
instance exceeded its max connections (70? or so, while normally the
connections stay below 10).
I git bisected the culprit to be
https://github.com/django/django/commit/36fa071d6ebd18a61c4d7f1b5c9d17106134bd44,
which is what Carlton Gibson suspected.
We are also running uvicorn.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:21>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Andreas Pelme):
We have been using `CONN_MAX_AGE=300` since it was introduced in Django
1.6 and rely in it for not having to reconnect to the database in each
http request. This change really caught us off guard. We upgraded from
django 3.2 to 4.0 and our site went completely down in a matter of seconds
when all database connections was instantly depleted.
Giving each http request its own async context makes a lot of sense and is
a good change in itself IMO. But I would argue that this change is not
backward compatible. `CONN_MAX_AGE` does still "technically" work but it
does clearly not behave as it has been doing for the last 10 years.
Specifying `CONN_MAX_AGE` is recommended in a lot of places, including
Django's own docs:
- https://docs.djangoproject.com/en/4.2/ref/databases/#persistent-
database-connections
- https://devcenter.heroku.com/articles/python-concurrency-and-database-
connections
At the very least, I think this needs to be clearly called out in the
release notes and docs on "Persistent connections". I think we need to
deprecate/remove `CONN_MAX_AGE`. Or is there even a reason to keep it
around?
I am very much in favor of getting basic db connection pooling into
django. We will try to give https://github.com/django/django/pull/16881 a
spin and put it in production and report back. Would love to have
something like that available out of the box in Django! We use Postgres
and would be happy with having such a pool which would replace
CONN_MAX_AGE for our use case.
However, that would only work for postgres. What is the situation with
mysql/oracle? Does mysqlclient come with a pool like psycopg?
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:22>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Sarah Boyce):
Replying to [comment:22 Andreas Pelme]:
> However, that would only work for postgres. What is the situation with
mysql/oracle? Does mysqlclient come with a pool like psycopg?
Oracle: https://python-
oracledb.readthedocs.io/en/latest/user_guide/connection_handling.html#connpooling
mysqlclient doesn't appear to support this out of the box. Looks like
mysql-connector-python would have support though:
https://dev.mysql.com/doc/connector-python/en/connector-python-connection-
pooling.html 🤔
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:23>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Sarah Boyce (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:24>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Sarah Boyce):
* has_patch: 0 => 1
Comment:
Will need to add solutions for other backends but don't see a reason why
we can't do this incrementally - the current patch is for postgreSQL:
https://github.com/django/django/pull/17594
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:25>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Florian Apolloner):
Well, I guess the main question is if we want to create our own pool
implementation or reuse what the database adapters provide and assume that
they can do it better for their database than we can do it generically :D
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:26>
Django
-------------------------------------+-------------------------------------
| Boyce
Type: New feature | Status: assigned
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Sarah Boyce
* needs_better_patch: 0 => 1
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:27>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:28>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Dmytro Litvinov (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:29>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Sarah Boyce):
There is already a ticket (and now a PR) to support database connection
pools in Oracle: #7732
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:30>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
As a user of Django, I was looking through the steps needed to optimize my
application, and came across
- https://docs.djangoproject.com/en/5.0/topics/performance/#other-
database-related-tips
It was then after a long amount of research/reading that I came across
this ticket. We are planning to soon upgrade our application to use
uvicorn workers and run under ASGI so that we can serve web sockets
alongside our HTTP API, and thus we now have pause to perform this
standard optimization due to this issue.
Questions:
1. Does this issue affect all ASGI Django HTTP endpoints, even synchronous
ones (e.g. no `async`, no `database_sync_to_async()`, etc.)?
2. Should the docs be updated to add a warning about the fact that
persistent connections are not currently fully compatible with ASGI? I'd
be happy to open a PR as it would have saved me personally a lot of time
if I had discovered this earlier in my research process.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:31>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
async | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:32>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Ready for
async | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
In [changeset:"fad334e1a9b54ea1acb8cce02a25934c5acfe99f" fad334e]:
{{{#!CommitTicketReference repository=""
revision="fad334e1a9b54ea1acb8cce02a25934c5acfe99f"
Refs #33497 -- Added connection pool support for PostgreSQL.
Co-authored-by: Florian Apolloner <flo...@apolloner.eu>
Co-authored-by: Ran Benita <r...@unusedvar.com>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:33>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Sarah
| Boyce
Type: New feature | Status: assigned
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
async |
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 1 => 0
* stage: Ready for checkin => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:34>
Django
-------------------------------------+-------------------------------------
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:35>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
I have created a pull request for database connection pool support in
oracle : https://github.com/django/django/pull/17834
It would be great if people experiencing the same problem could test this
with oracle backend (this would probably help in getting it merged).
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:36>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Suraj Shaw (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:37>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
For Postgres users, will the new Django 5.1 postgres connection pools
mitigate this issue? Should ASGI users use this rather than persistent
connections?
- https://docs.djangoproject.com/en/5.1/releases/5.1/#postgresql-
connection-pools
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:38>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Yiwei Gao (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:39>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
In [changeset:"7380ac57340653854bc2cfe0ed80298cdac6061d" 7380ac5]:
{{{#!CommitTicketReference repository=""
revision="7380ac57340653854bc2cfe0ed80298cdac6061d"
Fixed #35688 -- Restored timezone and role setters to be PostgreSQL
DatabaseWrapper methods.
Following the addition of PostgreSQL connection pool support in
Refs #33497, the methods for configuring the database role and timezone
were moved to module-level functions. This change prevented subclasses
of DatabaseWrapper from overriding these methods as needed, for example,
when creating wrappers for other PostgreSQL-based backends.
Thank you Christian Hardenberg for the report and to
Florian Apolloner and Natalia Bidart for the review.
Regression in fad334e1a9b54ea1acb8cce02a25934c5acfe99f.
Co-authored-by: Natalia <124304+...@users.noreply.github.com>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:40>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
In [changeset:"26c06671d9f9ff679be5e290b0752a45e582ce0c" 26c0667]:
{{{#!CommitTicketReference repository=""
revision="26c06671d9f9ff679be5e290b0752a45e582ce0c"
[5.1.x] Fixed #35688 -- Restored timezone and role setters to be
Following the addition of PostgreSQL connection pool support in
Refs #33497, the methods for configuring the database role and timezone
were moved to module-level functions. This change prevented subclasses
of DatabaseWrapper from overriding these methods as needed, for example,
when creating wrappers for other PostgreSQL-based backends.
Thank you Christian Hardenberg for the report and to
Florian Apolloner and Natalia Bidart for the review.
Regression in fad334e1a9b54ea1acb8cce02a25934c5acfe99f.
Co-authored-by: Natalia <124304+...@users.noreply.github.com>
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:41>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Replying to [comment:38 johnthagen]:
mitigate this issue? Should ASGI users use this rather than persistent
connections?
>
> - https://docs.djangoproject.com/en/5.1/releases/5.1/#postgresql-
connection-pools
issue. In my testing, enabling connection pooling in an ASGI context
causes connection leaks. Even with a very high max connection count and a
small timeout value, I'm seeing occasional `OperationalError: couldn't get
a connection after X sec` errors.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:42>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
> Even with a very high max connection count and a small timeout value,
I'm seeing occasional `OperationalError: couldn't get a connection after X
sec` errors.
error if you are already running out of connections. Whether there really
is a leak or not is impossible to tell without having more information
about your codebase and settings.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:43>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Replying to [comment:43 Florian Apolloner]:
error if you are already running out of connections.
answer ~2 requests per second, average response time is about 400ms. It
shouldn't take many connections to service this workload (even one
connection should work, I think), and yet, with pool timeouts set to 30s
and the pool max size set to 16, I'm seeing many such errors. Which is why
it seems to me that the new pooling support hasn't solved this particular
problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:44>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Ok, I'd recommend enabling pool logging
(https://www.psycopg.org/psycopg3/docs/advanced/pool.html#pool-operations-
logging) and see where it goes south (also check the stats
https://www.psycopg.org/psycopg3/docs/advanced/pool.html#pool-stats).
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:45>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Did anyone figure out what the right thing to do here with Django 5.1 and
ASGI (Uvicorn) with Postgres. The above comment suggests that connection
pooling doesn't work, which is super confusing. How are other folks
handling this?
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:46>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Your best bet for now is to disable persistent connections and deploy
PgBouncer (or the equivalent for your RDBMS) between Django and your
database server.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:47>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Interesting. It looks like as opposed to dseb, other people have found
success with connection pooling: https://forum.djangoproject.com/t
/operationalerror-sorry-too-many-clients-already/16221/34.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:48>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Are you using ASGI? This ticket is only relevant if you're using ASGI.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:49>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Yes, I am trying to get Uvicorn to work with Postgres.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:50>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: (none)
Type: New feature | Status: new
Component: Database layer | Version: 4.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
I think there is a bit of a missunderstanding about this ticket and what
the connection pool can do and how.
First off, let me start with the initial description of the ticket, namely
that persistent connections do not work with ASGI. Yes this is correct, is
by design and will stay that way. The reason for this is that persistent
connections as implemented in Django are basically persistent per thread
identifier. With ASGI you basically get a new thread identifier per
request and as such a new connection. The old connections are not getting
cleaned up at all quickly resulting in an exhaustion of the connection
limits.
With the connection pool you are actually able to reuse those connections
because they don't have a thread affinity anymore. If not this is yet
another bug that should be fixed, but I think this should work and so far
noone has shown any logs or an example project to the contrary and I will
also not waste my time if there is no effort in helping by providing logs
etc…
What will not work though is that the connection pool will make your
server magically be massively concurrently. The way connection handling in
Django currently works is that the connection is checked out at the first
SQL operation in a request and returned at the **end** of the request. So
the max size of the pool basically sets a hard limit on how many request
you can handle in parallel holding a connection. This is basically
equivalent to using no connection pool inside Django and pgbouncer in
`pool_mode = session`. If you have only have a handful of views that are
accessing the database and also doing a lot of work (ie the response time
is long) then you probably can manually close the connection mid view
which will return the connection to the pool allowing for more concurrent
requests.
A small example of this might look like this ([syntax] errors to be
expected):
{{{#!python
from django.db import connection
async def my_long_running_view(request):
my_tasks = list(Task.objects.all()) # Force the query to execute now
connection.close() # Close the connection and as such release back to
the pool
for task in tasks: # Note: I know that this could be done in parallel
as well, but that is besides the point here
await some_long_running_operation(task)
# Queries here will checkout a new connection from the pool
}}}
So yes, I do think that the connection pool in Django does solve the
problem of persistent connections not working in ASGI, what it doesn't do
is providing a mode that behaves like pgbouncers `pool_mode =
transaction`. This would certainly be a worthwile improvement but given
the limited feedback on pooling so far I never bothered implementing it.
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:51>
Django
-------------------------------------+-------------------------------------
| Gibson
(models, ORM) |
Severity: Normal | Resolution:
Keywords: ASGI, Database, | Triage Stage: Accepted
async |
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
* owner: (none) => Carlton Gibson
Added a [https://github.com/django/django/pull/19266 PR to clarify the
docs here].
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:52>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Carlton
| Gibson
Type: New feature | Status: assigned
Severity: Normal | Resolution:
async | checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:53>
Django
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Carlton
| Gibson
(models, ORM) |
async | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: => fixed
* status: assigned => closed
Comment:
In [changeset:"8713e4ae96817a0c7be3f7a8fee25a7c7f819721" 8713e4ae]:
{{{#!CommitTicketReference repository=""
revision="8713e4ae96817a0c7be3f7a8fee25a7c7f819721"
Fixed #33497 -- Doc'd that persistent DB connections should be disabled in
ASGI and async modes.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:54>
Django
async mode
Reporter: Stenkar | Owner: Carlton
| Gibson
Type: New feature | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: ASGI, Database, | Triage Stage: Ready for
async | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* summary: Database persistent connections do not work with ASGI in 4.0 =>
Document that database persistent connections do not work with ASGI
nor async mode
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:55>
Django
async mode
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Carlton
| Gibson
Type: New feature | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: ASGI, Database, | Triage Stage: Ready for
async | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
{{{#!CommitTicketReference repository=""
revision="c779808c8e580efdcc27d10bda1323c4ea74a8f5"
[5.2.x] Fixed #33497 -- Doc'd that persistent DB connections should be
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/33497#comment:56>
Django
async mode
-------------------------------------+-------------------------------------
Reporter: Stenkar | Owner: Carlton
| Gibson
Type: New feature | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: fixed
Keywords: ASGI, Database, | Triage Stage: Ready for
async | checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Natalia <124304+nessita@…>):
{{{#!CommitTicketReference repository=""
revision="ab4bb5b2f93d5bb4e1375594adad9d8c596fb8a7"
[5.1.x] Fixed #33497 -- Doc'd that persistent DB connections should be
Backport of 8713e4ae96817a0c7be3f7a8fee25a7c7f819721 from main.
}}}
--