#31208: Index introspection fails on Postgresql in presence of schema copy
-------------------------------------+-------------------------------------
               Reporter:  Shai       |          Owner:  Shai Berger
  Berger                             |
                   Type:  Bug        |         Status:  assigned
              Component:  Database   |        Version:  master
  layer (models, ORM)                |
               Severity:  Normal     |       Keywords:
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 Take a normal database schema created by Django.

 Duplicate it under a different schema name (e.g. `pg_dump` it into a file,
 `ALTER SCHEMA public RENAME TO other`, and then `psql` the dump file).

 Following this operation, index introspection fails -- if you look for an
 index for a column, it will not be found, because the introspection
 queries now return the columns lists doubled.

 In details: For a Postgresql connection `conn`, the function
 `conn.introspection.get_constraints()`  returns a dictionary whose keys
 are the constraint and index names and whose values are themselves
 dictionaries of information for constraints and indexes. In the situation
 described above, the `'columns'` entry in these dictionaries has the
 contents `['column_name', 'column_name']` where it should have just
 `['column_name']`. When Django code later looks for indexes for the
 specified columns, it compares this entry to `['column_name']`, and since
 they are not equal, the index will not be found.

 Context:

 We sometimes like to take database contents from one machine and recreate
 the database on another.

 In cases where the target database cluster already had some contents, we
 like to preserve it first by renaming the schema. We usually delete the
 renamed schema once the new schema creation completes successfully, but
 someone forgot it and our code which relied on the introspection erred
 (the schemas in our case were not exact duplicates, but similar enough).

 Found this on 1.11, but the relevant code is the same on master:

-- 
Ticket URL: <https://code.djangoproject.com/ticket/31208>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.805f382c7e5378338135795aa428686a%40djangoproject.com.

Reply via email to