id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
30266	Migrating a model's default primary key to a BigAutoField causes Postgres sequence to lose owner	Dolan Antenucci	Dolan Antenucci	"== Summary of Issue ==
Start with the following models (below assumes application name is ""sandbox""):

{{{#!python
class Test1(models.Model):
    id = models.BigAutoField(primary_key=True)
    name = models.CharField(max_length=100)

class Test2(models.Model):
    name = models.CharField(max_length=100)
}}}

After migrating, go the the `dbshell` and run `\d sandbox_test1_id_seq` and `\d sandbox_test2_id_seq`.  The results will include ""Owned by: public.sandbox_test1.id"" and ""Owned by: public.sandbox_test2.id"" respectively.

Next, change Test2 to a `BigIntField`:

{{{#!python
class Test2(models.Model):
    id = models.BigAutoField(primary_key=True)
    name = models.CharField(max_length=100)
}}}

Make a new migration, migrate, and then go back to `dbshell` and run `\d sandbox_test2_id_seq`.  There will no longer be an owner listed for this sequence.

== Result of this issue ==
When using `loaddata` with fixtures on the `Test2` model, the sequence will not be incremented because the command Django uses to reset the sequence for the primary key fails.  Specifically, in the [https://github.com/django/django/blob/master/django/db/backends/postgresql/operations.py#L157 postgres backend], Django calls the postgres function `pg_get_serial_sequence(<table>, <column>)`, which returns nothing when the sequence is missing an owner.

This can be verified in postgres shell via `select pg_get_serial_sequence('sandbox_test1', 'id');` and `select pg_get_serial_sequence('sandbox_test2', 'id');`

The result is that after the fixture is loaded, any other inserts will fail because their primary keys will conflict with those in the fixture.

== Potential fixes ==
1. It seems like `makemigrations` should be setting the sequence owner, or using a different command to migrate so that the sequence owner information is not lost.  For example, the [https://www.postgresql.org/docs/10/datatype-numeric.html#DATATYPE-SERIAL postgres docs on serial columns] show that this can be done with `ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname;`
2. For tables already migrated and missing the owner information, perhaps the `makemigrations` command needs to confirm that the owner information is set correctly.
3. Not a fan of this solution myself, but one could also change the sequence is reset the [https://github.com/django/django/blob/master/django/db/backends/postgresql/operations.py#L157 postgres backend] (i.e., not use `pg_get_serial_sequence`)

Long-term, maybe `makemigrations` should be using postgres's SERIAL and BIGSERIAL field types, which automatically create the sequence and set the sequence owner."	Bug	assigned	Migrations	1.11	Normal		postgres migration		Accepted	1	0	0	1	0	0