Check your database.yml config, production part, if it is correct. Then ensure Postgresql server is running on the production server and the application (as a user) has access rights. I assume "deployer" is the user, so check this user has all the necessary rights.
From the error it looks like you are trying to rename the
client_infos table to
clients but the
client_infos table does not exist, but do you not have an earlier migration which created the
If you don't have a migration which creates the
client_infos table, then where did it come from? Did you create it manually? All changes to the database should have an accompanying migration.
If you do have a migration for the
client_infos table, the
schema_migrations database table (which is where Rails keeps a record of what migrations have run) may of somehow got out of sync. Given you are deploying for the first time, its probably worth dropping the whole database and starting again.
What I don't understand is why the migration is running at all? Why isn't the the database just being created from the schema on the first run
If written correctly, the migrations should have the same effect as loading the schema, they will just do it incrementally. You can of course manually load the schema if you wish, but Capistrano will not do this as it is quite a dangerous thing to run (you likely never want to recreate your production database)
db:migrate takes the migration files and executes them. so if a table doesn't exist, it will tell you that so. If your deploy is the first deploy to that machine, or that the DB configured is yet have been initialized you should do:
this is will create all tables
2 Run the Migrations
Here obviously, you need to have migrations in place.
It is highly recommended not to load a schema (unless you have no choice) since its hard to work on the schema after (rollbacking, etc) but if you have no choice you can do rake
see this for more info