Opened 2 years ago

Last modified 13 months ago

#29345 new Bug

Migrations that recreate constraints can fail on PostgreSQL if table is not in public schema

Reported by: Olav Morken Owned by: nobody
Component: Migrations Version: 2.0
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The django.db.backends.postgresql.introspection.get_constraints(...)-function contains an SQL expression that assumes that all tables are in the public schema:

The last few lines read:

            JOIN pg_class AS cl ON c.conrelid = cl.oid
            JOIN pg_namespace AS ns ON cl.relnamespace = ns.oid
            WHERE ns.nspname = %s AND cl.relname = %s
        """, ["public", table_name])

The result is that it fails to find any constraints for tables that are not in the public schema. This either leaves us with two identical constraints, when it fails to delete the old, or results in an exception when it subsequently tries to recreate a constraint that it should have deleted:

django.db.utils.ProgrammingError: constraint "migration_app_testref_test_id_bce0807a_fk" for relation "migration_app_testref" already exists

A simple fix is to not check for the public schema, but instead check visibility using pg_catalog.pg_table_is_visible(cl.oid):

            JOIN pg_class AS cl ON c.conrelid = cl.oid
            WHERE cl.relname = %s AND pg_catalog.pg_table_is_visible(cl.oid)
        """, ["public", table_name])

This appears to give the correct result, even when there are multiple tables with the same name in the database.

I have attached a migration file and models file for a simple app migration_app that reproduces this problem. To be able to reproduce it, you must use a custom schema search path when connecting to PostgreSQL, either by setting it as the default for the role, or by specifying it in the connection options:

    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'migration_test',
        'HOST': 'localhost',
        'USER': 'postgres',
        'OPTIONS': {
            'options': '-c search_path=testschema,public',

Attachments (3) (2.2 KB) - added by Olav Morken 2 years ago.
Database migrations for migration_app (156 bytes) - added by Olav Morken 2 years ago. for migration_app
2_fk_constraints.png (246.0 KB) - added by Emre Kartoglu 16 months ago.

Download all attachments as: .zip

Change History (6)

Changed 2 years ago by Olav Morken

Attachment: added

Database migrations for migration_app

Changed 2 years ago by Olav Morken

Attachment: added for migration_app

comment:1 Changed 2 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

Changed 16 months ago by Emre Kartoglu

Attachment: 2_fk_constraints.png added

comment:2 Changed 16 months ago by Emre Kartoglu

I was trying to reproduce this issue. Although I failed to reproduce it using the files attached by Olav, I did notice another potential issue in the process: Django migration created 2 foreign key constraints both pointing from the same table&column to the same table&column. The attached file 2_fk_constraints.png​ shows what I mean. Should we create a ticket for this? I wonder if solving 29345 would solve this too, or vice versa.

comment:3 Changed 13 months ago by Dominique PERETTI

Hit by this as well, and was about to file the exact same bug report.

Obviously any query referring to the "public" schema in the postgresql backend code is bound to cause issues to people who use multiple connections and fancy search_paths.

The only workaround I can think of is to not use a schema named "public" at all.

Note: See TracTickets for help on using tickets.
Back to Top