multiprocessing works (on UNIX systems) by forking the current process. If you have an existing database connection, this will leave the two processes (the current one and the new one) with the same database connection. Trying to use it from both is bad. Create a new database connection in the child process instead.
In most cases this means that the previous SQL statement failed to execute. In this case you should:
Enable SQL logging, see the following snippet to paste in settings.py
Set DEBUG=1, or SQL won't be logged
Run runserver again, and you should see all SQL queries in the console
Execute the last SQL queries directly in your database, you should then find which queries fail and then you should be able to debug them - or open a new question which is specific to the query that causes the problem. You can use phpMyAdmin, or directly a CLI client, or whatever database client, to execute the SQL queries one by one until you find the one that needs some love.
SQL Logging configuration:
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'formatters': {
'simple': {
'format': '%(levelname)s %(message)s',
},
},
'handlers': {
'console':{
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'simple'
},
},
'loggers': {
'django': {
'handlers': ['console'],
'level': 'DEBUG',
},
}
}
If this configuration does not provide any additional console output with runserver
, then feel free to try django-autocomplete-light's example test_project:
Read and paste the installation commands in /tmp
Change dir to autocomplete_light_env/src/django-autocomplete-light/test_project
Open test_project/settings.py
, replace the LOGGING
configuration by the one above
Runserver and open your browser
Your console will look like:
Validating models...
0 errors found
Django version 1.4.1, using settings 'test_project.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
DEBUG (0.001) SELECT "django_content_type"."id", "django_content_type"."name", "django_content_type"."app_label", "django_content_type"."model" FROM "django_content_type" WHERE ("django_content_type"."model" = taggable AND "django_content_type"."app_label" = charfield_autocomplete ); args=('taggable', 'charfield_autocomplete')
DEBUG (0.000)
SELECT DISTINCT "tagging_tag".id, "tagging_tag".name
FROM
"tagging_tag"
INNER JOIN "tagging_taggeditem"
ON "tagging_tag".id = "tagging_taggeditem".tag_id
INNER JOIN "charfield_autocomplete_taggable"
ON "tagging_taggeditem".object_id = "charfield_autocomplete_taggable"."id"
WHERE "tagging_taggeditem".content_type_id = 11
GROUP BY "tagging_tag".id, "tagging_tag".name
ORDER BY "tagging_tag".name ASC; args=[]
Best Answer
This is what postgres does when a query produces an error and you try to run another query without first rolling back the transaction. (You might think of it as a safety feature, to keep you from corrupting your data.)
To fix this, you'll want to figure out where in the code that bad query is being executed. It might be helpful to use the log_statement and log_min_error_statement options in your postgresql server.