syncdb fails with the auth application

[Kelly Miller]

I run python manage.py syncdb -v on a new database and it fails. I'm running python 2.5, PostgreSql 8.3 and use Pycopg2 Version 2.0.7

The error I see follows:

Running post-sync handlers for application auth
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "/Library/Python/2.5/site-packages/django/core/management/__init__.py", line 334, in execute_manager
    utility.execute()
  File "/Library/Python/2.5/site-packages/django/core/management/__init__.py", line 295, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 77, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 96, in execute
    output = self.handle(*args, **options)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 178, in handle
    return self.handle_noargs(**options)
  File "/Library/Python/2.5/site-packages/django/core/management/commands/syncdb.py", line 101, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/Library/Python/2.5/site-packages/django/core/management/sql.py", line 205, in emit_post_sync_signal
    interactive=interactive)
  File "/Library/Python/2.5/site-packages/django/dispatch/dispatcher.py", line 132, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/Library/Python/2.5/site-packages/django/contrib/auth/management/__init__.py", line 25, in create_permissions
    ctype = ContentType.objects.get_for_model(klass)
  File "/Library/Python/2.5/site-packages/django/contrib/contenttypes/models.py", line 28, in get_for_model
    defaults = {'name': smart_unicode(opts.verbose_name_raw)},
  File "/Library/Python/2.5/site-packages/django/db/models/manager.py", line 84, in get_or_create
    return self.get_query_set().get_or_create(**kwargs)
  File "/Library/Python/2.5/site-packages/django/db/models/query.py", line 329, in get_or_create
    sid = transaction.savepoint()
  File "/Library/Python/2.5/site-packages/django/db/transaction.py", line 188, in savepoint
    connection._savepoint(sid)
  File "/Library/Python/2.5/site-packages/django/db/backends/__init__.py", line 37, in _savepoint
    self.connection.cursor().execute(self.ops.savepoint_create_sql(sid))
psycopg2.InternalError: SAVEPOINT can only be used in transaction blocks

[Malcolm Tredinnick]

I tried to repeat this, without success. If I start a new project with django-admin.py startproject foo, create a database with PostgreSQL and then use the postgresql_psycopg2 engine and change nothing else, I can't repeat this error. The report is also missing something else, since manage.py syncdb -v leads to an "invalid option" error (possibly you mean --verbosity=2` or something like that?).

Repeating this is going to be the first (and a necessary) step towards fixing it, so can you please provide the steps needed to reproduce the issue. What else, beyond just running startproject is involved?

I can't see why the "not in transaction" error is reported, since everything is pretty much automatically in a transaction with the DB API and PostgreSQL, so I'm a bit stuck as to how to create this situation.

[Kelly Miller]

To repeat the error I did the following

python django-admin.py startproject test1

I then edited the newly created settings.py file to point to a new database I just created. Here are the lines I changed:

DATABASE_ENGINE = 'postgresql_psycopg2'			  
DATABASE_NAME = 'test1'			 
DATABASE_USER = 'test1'			 
DATABASE_PASSWORD = 'test'		   
DATABASE_HOST = ''			   
DATABASE_PORT = ''			

I then ran the sync command and got the following :

python manage.py syncdb
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "/Library/Python/2.5/site-packages/django/core/management/__init__.py", line 334, in execute_manager
    utility.execute()
  File "/Library/Python/2.5/site-packages/django/core/management/__init__.py", line 295, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 77, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 96, in execute
    output = self.handle(*args, **options)
  File "/Library/Python/2.5/site-packages/django/core/management/base.py", line 178, in handle
    return self.handle_noargs(**options)
  File "/Library/Python/2.5/site-packages/django/core/management/commands/syncdb.py", line 101, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/Library/Python/2.5/site-packages/django/core/management/sql.py", line 205, in emit_post_sync_signal
    interactive=interactive)
  File "/Library/Python/2.5/site-packages/django/dispatch/dispatcher.py", line 132, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/Library/Python/2.5/site-packages/django/contrib/auth/management/__init__.py", line 25, in create_permissions
    ctype = ContentType.objects.get_for_model(klass)
  File "/Library/Python/2.5/site-packages/django/contrib/contenttypes/models.py", line 28, in get_for_model
    defaults = {'name': smart_unicode(opts.verbose_name_raw)},
  File "/Library/Python/2.5/site-packages/django/db/models/manager.py", line 84, in get_or_create
    return self.get_query_set().get_or_create(**kwargs)
  File "/Library/Python/2.5/site-packages/django/db/models/query.py", line 329, in get_or_create
    sid = transaction.savepoint()
  File "/Library/Python/2.5/site-packages/django/db/transaction.py", line 188, in savepoint
    connection._savepoint(sid)
  File "/Library/Python/2.5/site-packages/django/db/backends/__init__.py", line 37, in _savepoint
    self.connection.cursor().execute(self.ops.savepoint_create_sql(sid))
psycopg2.InternalError: SAVEPOINT can only be used in transaction blocks

[Malcolm Tredinnick]

The only difference between my system and yours is that I'm only running PostgreSQL 8.2.9 and I can't repeat this.

So we need to see if this can be repeated on a similar system. If so (or even in the interim) we need to work out why a transaction isn't in effect there. Moving to accepted just to get it off the unreviewed list, but I can't go any further on this at the moment.

[mrts]

I can't reproduce this:

$ dpkg -l python-psycopg2 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  python-psycopg 2.0.6-3        Python module for PostgreSQL

$ psql --version
psql (PostgreSQL) 8.3.3

$ grep DATABASE settings.py
DATABASE_ENGINE = 'postgresql_psycopg2'           # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
DATABASE_NAME = 'djtest'             # Or path to database file if using sqlite3.
DATABASE_USER = 'foo'             # Not used with sqlite3.
DATABASE_PASSWORD = ''         # Not used with sqlite3.
DATABASE_HOST = ''             # Set to empty string for localhost. Not used with sqlite3.
DATABASE_PORT = ''             # Set to empty string for default. Not used with sqlite3.

$ ./manage.py syncdb
Creating table auth_permission
Creating table auth_group
Creating table auth_user
Creating table auth_message
Creating table django_content_type
Creating table django_session
Creating table django_site

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (Leave blank to use 'foo'): 
E-mail address: foo@bar.com
Password: 
Password (again): 
Superuser created successfully.
Installing index for auth.Permission model
Installing index for auth.Message model

[mrts]

Still can't reproduce after installing latest psycopg.

$ sudo easy_install psycopg2
...
Best match: psycopg2 2.0.7
...
Installed /usr/lib/python2.5/site-packages/psycopg2-2.0.7-py2.5-linux-x86_64.egg

[Kelly Miller]

I figured it out. I got latest this morning but did not delete any *.pyc files. I just now cleared everything and then got latest. Everything now works. Sorry for the confusion

[bkroeze]

I can reliably reproduce this error. MacOSX, postgres 8.3.3, psycopg2-2.0.7, using exactly the same settings described above. It does not occur on my other dev machine, which has postgres 8.2.6.

I have tried removing .pyc files from psycopg2, and recompiling the module. No luck.

[Kelly Miller]

When I said I deleted pyc files to resolve the issue I meant for Django and not psycopg2. I actually deleted the whole Django folder and got it fresh from subversion. The problem then went away.

[James Bennett]

Above comment can't reproduce this, and neither can I.

[alexm]

I can reproduce the problem with python 2.5.2, postgreSQL 8.0.15, psycopg2 2.0.6 and a freshly checked out version of the django 1.1 (RELEASE) reliably, every time.

Traceback (most recent call last):
  File "manage.py", line 15, in <module>
    execute_manager(settings)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/__init__.py", line 362, in execute_manager
    utility.execute()
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/__init__.py", line 303, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/base.py", line 195, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/base.py", line 222, in execute
    output = self.handle(*args, **options)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/base.py", line 351, in handle
    return self.handle_noargs(**options)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/core/management/commands/syncdb.py", line 52, in handle_noargs
    tables = connection.introspection.table_names()
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/db/backends/__init__.py", line 483, in table_names
    return self.get_table_list(cursor)
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/db/backends/postgresql/introspection.py", line 30, in get_table_list
    AND pg_catalog.pg_table_is_visible(c.oid)""")
  File "/var/www/mydefence.artofdefence.com/django/django-1.1/django/db/backends/util.py", line 19, in execute
    return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: current transaction is aborted, commands ignored until end of transaction block

[anonymous]

Adding a print to the executed sql string shows this query:

SELECT c.relname
            FROM pg_catalog.pg_class c
            LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
            WHERE c.relkind IN ('r', 'v', '')
                AND n.nspname NOT IN ('pg_catalog', 'pg_toast')
                AND pg_catalog.pg_table_is_visible(c.oid) ()

executed by hand on my database does not return any content or error.

[Karen Tracey]

Your traceback doesn't show the same problem as originally reported. The problem reported in this ticket involved the error:

psycopg2.InternalError: SAVEPOINT can only be used in transaction blocks

reported during run of the post_sync signal. Your reported error is:

psycopg2.ProgrammingError: current transaction is aborted, commands ignored until end of transaction block

and there is no sign of the post_sync signal in the traceback.

Also, given the error reported, it is not the SQL of the current command that caused a problem, it is the previous command which triggered an error that has not been cleaned up. So it is unsurprising that you can manually successfully execute the sql which "causes" the error -- the problem is something earlier in the history of the DB connection being used by the command.

Anyway, I'm re-closing this and restoring the old resolution. Please open a new ticket for new problems. This one may match on broad summary, but the specifics are quite different so it is really a different problem.

[Jacob]

Milestone 1.0 deleted