After upgrading to Zammad 3.2.0-1575624531.d79c85cf.buster on Debian 10, I get this:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "active_job_locks" does not exist
LINE 8: WHERE a.attrelid = '"active_job_locks"'::regc...
: SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod,
c.collname, col_description(a.attrelid, a.attnum) AS comment
FROM pg_attribute a
LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum
LEFT JOIN pg_type t ON a.atttypid = t.oid
LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation
WHERE a.attrelid = '"active_job_locks"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
Any ideas how to solve this? Many thanks in advance!
so, if you are now running zammad 3.2.x with db version 20180327170847, then db patches was not applied. if single one patch fails to apply, then all patches after failed one all not applied also. this is my personal expirience. so, my advice for you:
get zammad 3.2 install archive, unpack it, look for sql patches in db folder.
check, what patch with 20180327170847 name actually applied to your db (install pgadmin and explore your db)
most definitely next patch after 20180327170847 failed to apply because of some problem. resolve this problem and try upgrade process again on working zammad 2.3. with your original, but fixed db.
optionally try to upgrade to zammad 3.1, because 3.2 has many db updates. I do not know, how big difference between 2.3 and 3.1 in terms of db updates.
this is my user class advice. I am not ruby or sql guru.
you can not migrate, if your db, for example, has already some table, what some patch want to create again. this will produce error and no any migrate, or, actually, upgrade. you need to have correct db, where version number exactly match with changes, made by corresponding patch file. then you can issue “db:migrate” command, what will try to apply all missed patches. IMHO.
Unfortunately, I cannot see, which table exactly failed. Going through all the patches is something I would like to avoid. I downgraded now to 3.1.0 which gives me a more-or-less working Zammad. Interestingly, the user table is shown as completely empty. I will try now a new update process, but will directly go to 3.1.0 and not via 3.2.0. If that fails, too, I have to check all the migrations.
when you do normal “yum update zammad”, capture terminal session to file. when update finished, look at captured log. each postgres db patch are shown in this log. and you can easily see, what patch are failed.
I was trying to update from 2.2 to 3.3, and it was failing every time. Migrations wouldn’t even start to run because they needed table active_jobs_locks to be present, which wasn’t. I tried @homat’s solution too, but it didn’t work, failing for the same reason. based on @Martin1’s comment, I updated first to version 3.1. Migrations ran fine. Then I updated from 3.1 to 3.3, and migrations ran fine again.
So, this might help anyone in the future save some days. I don’t know what’s the threshold but I think it’s good to be added to documentations that “updating from a version prior to XX you should first update to version YY and then to the latest version”.
As a complete side note, I found that the best way for updating elasticsearch from 5.5 to 7.6 is totally purging it, manually deleting nodes, and installing 7.6 from scratch