[Django] #31518: Postgres contrib app creates a connection for _all_ configured DBs on ready.
Django
ready.
--------------------------------------------+--------------------------
Reporter: Curtis Maloney | Owner: (none)
Type: Bug | Status: assigned
Component: contrib.postgres | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
--------------------------------------------+--------------------------
Whilst helping a client debug why a fresh deploy had created hundreds of
connections, I stumbled upon this.
In `django.contrib.postgres.apps.PostgresConfig` the `ready` function
iterates `django.db.connections`, checking if each connection has vendor
== 'postgres'.
This creates a connection per configured DB. It then does nothing to close
them afterwards.
This means the first connection to all DBs is once Django's setup is
complete, not the first request.
The issue of not closing connections seems irrelevant, since django
_should_ close them itself after requests; however, this is not the case
for use of the ORM from other jobs [for instance, task queues].
It's also not unreasonable to believe there are cases where a system is
built on the assumption DB connections will not be created until the first
request. This expectation is violated by this code.
## Possible steps:
1. document this behavor - we should do this anyway
2. make the `ready` function get DB Backends and test their `vender`
attribute _before_ getting a connection.
3. make the `ready` function _close_ connections once done.
I have begun a patch for (2), and will implement the rest once someone
agrees with this solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/31518>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
ready.
Reporter: Curtis Maloney | Owner: (none)
Type: Bug | Status: assigned
Component: contrib.postgres | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Curtis Maloney:
Old description:
> Whilst helping a client debug why a fresh deploy had created hundreds of
> connections, I stumbled upon this.
>
> In `django.contrib.postgres.apps.PostgresConfig` the `ready` function
> iterates `django.db.connections`, checking if each connection has vendor
> == 'postgres'.
>
> This creates a connection per configured DB. It then does nothing to
> close them afterwards.
>
> This means the first connection to all DBs is once Django's setup is
> complete, not the first request.
>
> The issue of not closing connections seems irrelevant, since django
> _should_ close them itself after requests; however, this is not the case
> for use of the ORM from other jobs [for instance, task queues].
>
> It's also not unreasonable to believe there are cases where a system is
> built on the assumption DB connections will not be created until the
> first request. This expectation is violated by this code.
>
> ## Possible steps:
>
> 1. document this behavor - we should do this anyway
> 2. make the `ready` function get DB Backends and test their `vender`
> attribute _before_ getting a connection.
> 3. make the `ready` function _close_ connections once done.
>
> I have begun a patch for (2), and will implement the rest once someone
> agrees with this solution.
New description:
Whilst helping a client debug why a fresh deploy had created hundreds of
connections, I stumbled upon this.
In `django.contrib.postgres.apps.PostgresConfig` the `ready` function
iterates `django.db.connections`, checking if each connection has vendor
== 'postgres'.
This creates a connection per configured DB. It then does nothing to close
them afterwards.
This means the first connection to all DBs is once Django's setup is
complete, not the first request.
The issue of not closing connections seems irrelevant, since django
_should_ close them itself after requests; however, this is not the case
for use of the ORM from other jobs [for instance, task queues].
It's also not unreasonable to believe there are cases where a system is
built on the assumption DB connections will not be created until the first
request. This expectation is violated by this code.
## Possible steps:
1. document this behavor - we should do this anyway
2. make the `ready` function get DB Backends and test their `vendor`
attribute _before_ getting a connection.
3. make the `ready` function _close_ connections once done.
I have begun a patch for (2), and will implement the rest once someone
agrees with this solution.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31518#comment:1>
Django
ready.
Reporter: Curtis Maloney | Owner: (none)
Type: Bug | Status: assigned
Component: contrib.postgres | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Curtis Maloney:
Old description:
> Whilst helping a client debug why a fresh deploy had created hundreds of
> connections, I stumbled upon this.
>
> In `django.contrib.postgres.apps.PostgresConfig` the `ready` function
> iterates `django.db.connections`, checking if each connection has vendor
> == 'postgres'.
>
> This creates a connection per configured DB. It then does nothing to
> close them afterwards.
>
> This means the first connection to all DBs is once Django's setup is
> complete, not the first request.
>
> The issue of not closing connections seems irrelevant, since django
> _should_ close them itself after requests; however, this is not the case
> for use of the ORM from other jobs [for instance, task queues].
>
> It's also not unreasonable to believe there are cases where a system is
> built on the assumption DB connections will not be created until the
> first request. This expectation is violated by this code.
>
> ## Possible steps:
>
> 1. document this behavor - we should do this anyway
> 2. make the `ready` function get DB Backends and test their `vendor`
> attribute _before_ getting a connection.
> 3. make the `ready` function _close_ connections once done.
>
> I have begun a patch for (2), and will implement the rest once someone
> agrees with this solution.
New description:
Whilst helping a client debug why a fresh deploy had created hundreds of
connections, I stumbled upon this.
In `django.contrib.postgres.apps.PostgresConfig` the `ready` function
iterates `django.db.connections`, checking if each connection has vendor
== 'postgres'.
This creates a backend per configured DB. It then does nothing to close
them afterwards.
This means the first connection to all DBs is once Django's setup is
complete, not the first request.
The issue of not closing connections seems irrelevant, since django
_should_ close them itself after requests; however, this is not the case
for use of the ORM from other jobs [for instance, task queues].
It's also not unreasonable to believe there are cases where a system is
built on the assumption DB connections will not be created until the first
request. This expectation is violated by this code.
## Possible steps:
1. document this behavior - we should do this anyway
2. make the `ready` function _close_ connections once done.
I have begun a patch, and will implement the rest once someone agrees with
this solution.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/31518#comment:2>
Django
ready.
Reporter: Curtis Maloney | Owner: (none)
Component: contrib.postgres | Version: 3.0
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Curtis Maloney):
* status: assigned => closed
* resolution: => invalid
Comment:
Seems I misinterpreted this code, and it's creating `DatabaseWrapper`
instances, but not necessarily connections. (calling it `conn` confused
me).
--
Ticket URL: <https://code.djangoproject.com/ticket/31518#comment:3>