v2 icon indicating copy to clipboard operation
v2 copied to clipboard

schema_version exists, but Miniflux tries to run migration

Open BerkhanBerkdemir opened this issue 2 years ago • 3 comments

Hello,

I have migrated my Miniflux 2.0.36 instance of off managed PostgreSQL. I guess I successfully ran pg_restore without errors. Then I modified /etc/miniflux.conf and I set DATABASE_URL as a valid URI. However, Miniflux unit did not work properly but reporting this

You must run the SQL migrations, the database schema is not up to date: current=v0, expected=v54

The table returns,

miniflux_production=# SELECT version FROM schema_version;
 version
---------
 54
(1 row)

For future reference, I used following command to restore the PostgreSQL dump

createdb -O miniflux -T template0 miniflux_production
pg_restore --verbose --no-acl --no-owner -h /var/run/postgresql/ -U postgres -d miniflux_production miniflux-production.dump

If I set RUN_MIGRATION=1, then PostgreSQL returns as schema_version exists. I have feeling that this report is related to

https://github.com/miniflux/v2/blob/ab3fdf509fe36f6cb4732efac0294562c83753c0/database/database.go#L71-L78

I tried to give information what you might need. Please directly ping me when you write a comment.

Thanks for this great project.

BerkhanBerkdemir avatar May 02 '22 16:05 BerkhanBerkdemir

If this is an installation issue, what should I do? Miniflux can't read the deployed table and assumes that there is nothing to run.

BerkhanBerkdemir avatar May 06 '22 13:05 BerkhanBerkdemir

Had the same issue, turns out the tables and sequences in the miniflux db were not owned by the user used by miniflux.

Here is the SQL I used to correct the ownership, probably a better/quicker way but it works:

ALTER TABLE public."acme_cache" OWNER TO miniflux;
ALTER TABLE public."api_keys" OWNER TO miniflux;
ALTER TABLE public."categories" OWNER TO miniflux;
ALTER TABLE public."enclosures" OWNER TO miniflux;
ALTER TABLE public."entries" OWNER TO miniflux;
ALTER TABLE public."feed_icons" OWNER TO miniflux;
ALTER TABLE public."feeds" OWNER TO miniflux;
ALTER TABLE public."icons" OWNER TO miniflux;
ALTER TABLE public."integrations" OWNER TO miniflux;
ALTER TABLE public."schema_version" OWNER TO miniflux;
ALTER TABLE public."sessions" OWNER TO miniflux;
ALTER TABLE public."user_sessions" OWNER TO miniflux;
ALTER TABLE public."users" OWNER TO miniflux;
ALTER SEQUENCE public."api_keys_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."categories_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."enclosures_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."entries_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."feeds_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."icons_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."sessions_id_seq" OWNER TO miniflux;
ALTER SEQUENCE public."users_id_seq" OWNER TO miniflux;

nikdoof avatar Jul 09 '22 13:07 nikdoof

turns out the tables and sequences in the miniflux db were not owned by the user used by miniflux

I can also confirm that this is because of missing permissions. Do you think that adding operator friendly message will mitigate this issue for not happening in the future?

BerkhanBerkdemir avatar Jul 21 '22 08:07 BerkhanBerkdemir