Yes, and something else strange is happening here. You mentioned that you ran
manage_db.sh upgrade after starting the server. You shouldn't need to run 'sh
manage_db.sh upgrade' after starting Galaxy on an empty database, since Galaxy
automatically runs the migration on first run. Are you doi
Your database is not cleanly dropped when you start up your Galaxy server -
notice all of the migration scripts that fail because table columns, etc
already exist. Here's an example:
> 0012_user_address DEBUG 2011-12-14 15:15:12,085 Adding column 'deleted' to
> request_type table failed: (Prog
Iry:
I've run this recently on postgres without any trouble.
Maybe the managedb_sh script is working on a different database than
galaxy_1, or maybe there is some leftover information in galaxy_1?
brad
On 1/3/12 6:59 AM, "Iry Witham" wrote:
>Hi Nate,
>
> I do not create any tables ma
Hi Nate,
I do not create any tables manually. I simply create the database and
setup users and roles. I do the following:
initdb D /local/postgresql/data
pg_ctl D /local/postgresql/data I /local/postgresql/pgsql.log start
createdb galaxy_1
Sudo su - postgres
pgsql galaxy_1
CREATE U
On Dec 21, 2011, at 2:49 PM, Iry Witham wrote:
> I have installed a new Galaxy server utilizing the November 18,2011
> distribution on a SLES 11 VM and cannot get it to launch cleanly. I am
> running postgreSQL v. 8.3.9 to create my database. Once the database is
> created and running I launc
