Postgres 18 has an apparent behavior change where, if a table is
renamed, it will not automatically rename the hidden internal
NOT NULL constraint for the primary key. In our "bundle refactor"
migration, we do the following:
* create zuul_build_new
* drop zuul_build
* rename zuul_build_new to zuul_build
(And the same for zuul_buildset)
With postgres 17, after the rename, we see the id column as:
id integer NOT NULL,
With postgres 18, it is:
id integer CONSTRAINT zuul_build_new_id_not_null NOT NULL,
Note the name of the constraint is based on the former name of the
table. This can be corrected with:
ALTER TABLE zuul_build rename constraint zuul_build_new_id_not_null
to zuul_build_id_not_null
After issuing that statement, the constraint no longer appears in
the schema.
We could address this in our alembic migrations in a number of ways:
1) We could add a rename statement to the bundle_refactor migration
2) We could remove the bundle_refactor migration
3) We could add a rename statement to a new migration
This change implements #3. In case anyone ran the bundle refactor
on Postgres 18, this should correct their installation and make it
consistent with the other cases. For everyone outside that situation,
the new migration will no-op.
This migration has been manually tested against postgres 17 and 18.
It has also been tested by:
* Initializing a new system on postgres 17 without this migration
* Upgrading postgres from 17 to 18
* Running this migration on 18
The docker-compose file is restored to running the latest version of
postgres.
Change-Id: Iee603eb8a7aae20011c75ea62e0bd0b94885b819
James E. Blair
86ce365b61