ERROR: cannot drop table users column email because other objects depend on it
DETAIL: trigger users_email_readonly on table users depends on table users column email
HINT: Use DROP … CASCADE to drop the dependent objects too.
AI-generated summary
The user oluies is attempting to restore a Discourse 1.9 backup onto a newer version (v2.3.0.beta9+184) installed via Docker, but encounters a PostgreSQL error related to column dependencies: “cannot drop table users column email because other objects depend on it” oluies. Stephen initially assumes this is a downgrade attempt, clarifying that downgrading isn’t supported and suggesting checking free space and disabling plugins. However, michaeld corrects that the user is restoring an old backup, not downgrading, and suggests the issue may stem from changes in how delayed column drops are handled in newer versions. oluies confirms they migrated from Bitnami to Docker and accidentally installed the latest beta version instead of v2.2. They reference a similar issue here oluies. michaeld provides a solution: run db:seed_fu before backing up or upgrading PostgreSQL to avoid the error. The discussion highlights compatibility challenges when restoring old backups onto newer Discourse versions and the importance of pre-upgrade database seeding.
So the docker install discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub install the LATEST… how to select a stable version?
Downgrading isn’t supported, you can’t roll back to beta or stable until they pass the current tests-passed. You can use the commit ID as per this topic, but it’s very unlikely a routine upgrade is the cause - Discourse isn’t prone to spontaneous combustion.
Do you have sufficient free space on the server? Have you disabled all plugins and re-tried?
OP is trying to restore a backup with a schema from 2017 so this is not what he is trying to do.
Might this be related to the fact that delayed column drops are working differently nowadays?
Fair enough, I was going by the title, which said he was upgrading to beta9 +184.
Yes I was using v1.9 earlier and now I was planning to upgrade to v2.2.
I switched from Bitnami to a dedicated Docker install. Somehow latest+latest was installed. So I got v2.3.0.beta9+184 where the backup import failed.
So have to look up how to install a specific docker version
Might be similar to this Trouble upgrading from 1.9.0.beta11
Yes! The solution basically is:
to avoid this just run db:seed_fu before you backup or upgrade Postgres
.