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.ba...@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 
<epani...@cshl.edu<mailto:epani...@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.ba...@gmail.com<mailto:dannon.ba...@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 
<epani...@cshl.edu<mailto:epani...@cshl.edu><mailto:epani...@cshl.edu<mailto:epani...@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.


___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to