Re: [galaxy-dev] Potential database corruption with local galaxy instance
% sh manage_db.sh downgrade 92 % sh manage_db.sh upgrade The downgrade to 92 and upgrade created job.params.
This is progress. You should be able to run jobs again, yes?
Unfortunately, we are still getting errors about duplicate key values. The debug output when I try to export a history to a file is shown below my signature. Is there anything that was updated recently that would change primary keys?
Primary keys are handled by SQLAlchemy, not Galaxy, so that's not the problem. I would guess the issue arose due to the missing 'params' column in job. This can likely be fixed by deleting all the rows in the job_history_export_table: DELETE FROM job_export_history_archive; The only downside to this operation is that existing history archives won't be found and will have to be recreated. Best, J.
To update our problems from the other day, it appears like there were multiple issues, at least one of which involved the postgres sequences. There were already id values in several tables that matched those that were being assigned by the sequence, creating errors involving duplicate keys. Offsetting the next assigned value of the sequences +1 seems to have fixed at least some of these problems. Cheers, dave -- David O'Connor http://labs.pathology.wisc.edu/oconnor ph: 608-301-5710 On Wednesday, April 18, 2012 at 11:42 AM, Jeremy Goecks wrote:
% sh manage_db.sh (http://manage_db.sh/) downgrade 92 % sh manage_db.sh (http://manage_db.sh/) upgrade
The downgrade to 92 and upgrade created job.params.
This is progress. You should be able to run jobs again, yes?
Unfortunately, we are still getting errors about duplicate key values. The debug output when I try to export a history to a file is shown below my signature. Is there anything that was updated recently that would change primary keys?
Primary keys are handled by SQLAlchemy, not Galaxy, so that's not the problem. I would guess the issue arose due to the missing 'params' column in job. This can likely be fixed by deleting all the rows in the job_history_export_table:
DELETE FROM job_export_history_archive;
The only downside to this operation is that existing history archives won't be found and will have to be recreated.
Best, J.
participants (2)
-
David O'Connor -
Jeremy Goecks