Correction. The job has entered the "waiting to run" phase, and doesn't appear to be leaving it. There is nothing of note in the server log. ________________________________ From: Paniagua, Eric Sent: Tuesday, May 27, 2014 12:41 PM To: Dannon Baker Cc: galaxy-dev@lists.bx.psu.edu Subject: RE: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host I have created a fresh dump with $ pg_dump -U galaxyprod galaxyprod This time the import proceeded cleanly. Further, using PostgreSQL 9.1, I no longer get the error regarding a read only database cursor and getting the next history item number. I am currently running a test job to confirm that things are working as expected. However, just the fact that this job is running is a very good sign. ________________________________ From: Dannon Baker [dannon.baker@gmail.com] Sent: Tuesday, May 27, 2014 11:58 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible. If there's an error this time around, note it and send it on over and we can figure out where to go from there. On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric <epaniagu@cshl.edu<mailto:epaniagu@cshl.edu>> wrote: The "dataset" table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... ________________________________ From: Dannon Baker [dannon.baker@gmail.com<mailto:dannon.baker@gmail.com>] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu<mailto:galaxy-dev@lists.bx.psu.edu> Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric <epaniagu@cshl.edu<mailto:epaniagu@cshl.edu><mailto:epaniagu@cshl.edu<mailto:epaniagu@cshl.edu>>> wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran "sh manage_db.sh upgrade" and it upgraded from schema 114 to 118 without error messages. I then ran "sh ./scripts/migrate_tools/0010_tools.sh install_dependencies" and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my "history_dataset_association" table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any.