Django-cms: psycopg2.OperationalError: database "devdb" is being accessed by other users

[aubricus]

Summary

I am hitting this error when using reset_db from django-extensions.

psycopg2.OperationalError: database "devdb" is being accessed by other users
DETAIL:  There is 1 other session using the database.

This is happening when I've created a bare cms apphook application (i.e., just defines a CMSApp extension and registers via apphook_pool.register).

I've tracked the problem down to these lines in appresolover.py: https://github.com/divio/django-cms/blob/release/3.4.x/cms/appresolver.py#L186-L192

Looking at the code I would expect it catch the Operational error in the try block but it doesn't (for me).

It's worth noting that I tried in several places to just catch any Exception at all and still hit this error.

Thanks very much for taking the time to help.

Here's the full error stack trace:

python manage.py reset_db --noinput
Traceback (most recent call last):
  File "manage.py", line 8, in <module>
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 359, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 294, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 345, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.5/site-packages/django_extensions/management/utils.py", line 58, in inner
    ret = func(self, *args, **kwargs)
  File "/usr/local/lib/python3.5/site-packages/django_extensions/management/commands/reset_db.py", line 167, in handle
    cursor.execute(drop_query)
psycopg2.OperationalError: database "devdb" is being accessed by other users
DETAIL:  There is 1 other session using the database.

Expected behaviour

python manage.py reset_db does not throw an error.

Actual behaviour

python manage.py reset_db throws an error

Environment

This is happening on my local development environment running in a docker (Alpine Linux 3.4.4) container that has python installed, and a db container running Debian GNU/Linux 8 (jessie) and Postgres 9.6.1.

• Python version: 3.5.2
• Django version: 1.10.7
• django CMS version: 3.4.2
• Database: Postgres, latest
• Django Extensions: 1.7.8

[czpython]

Hello @aubricus,
is your server running when you run the python manage.py reset_db command?

[aubricus]

@czpython

Thanks for responding so quickly.

Unfortunately my dev server is not running. I've also tested this locally through many docker client / container rebuilds and computer restarts to make sure there's no weird connection to the db just hanging around.

This feels related to the fact that (for reasons I fail to understand) that reset_db causes my urls.py to evaluate (and subsequently tries to load cms.urls). What I don't understand is why the try except block doesn't catch the OperationError (even when I modified the src myself to just catch any exception).

If it's useful I can try to put together a minimal build that replicates the issue.

[czpython]

The OperationalError is raised by the command itself not by django CMS, this is why the code you linked to does not handle it.

If you can, please provide us with docker image or something packaged which we can then use to reproduce this.

[aubricus]

@czpython Thanks again. I will put something together to reproduce the issue this week / coming weekend.

[czpython]

Hello @aubricus,
Any updates? :)

[aubricus]

@czpython Hey! Been getting just crushed by work. Will make some time this weekend. Thanks for checking in!

[aubricus]

Welp.

Just made some progress, actually :). I created this workaround, that overrides the reset_db command and disables system checks (as documented here). This prevents the manage.py session from loading urls.py during it's check cycle. Immediately I don't see any side effects to this.

Ultimately though, it feels like an issue with django_extensions needing to either disable system checks for reset_db or a least providing an option to.

Here's a Gist

I will file an issue over at django_extensions as well. Feel free to close this issue if you like.

Thanks!

[memorysaver]

I encounter similar issue within my own project. However, I found out that reset_db actually has -c argument to close all sessions and it solve this for good in a simple way. You can look into the code for the details.