fastmonkeys / stellar

Fast database snapshot and restore tool for development
MIT License
3.86k stars 119 forks source link

"database already exists" when restoring #33

Open ramonakira opened 10 years ago

ramonakira commented 10 years ago

When trying to restore the database, I get the following error:

sqlalchemy.exc.ProgrammingError: (ProgrammingError) database "d-demo" already exists
 '\n                ALTER DATABASE "stellar_d-demo_f9182c358a0a063cc6d6ec785140ec94_slave"  RENAME TO "d-demo"\n            ' {}

What am I missing? When I remove the database using pgAdmin before restoring, all is fine.

ramonakira commented 9 years ago

Apparently Postgresql needs database-names escaped when they contain "-". And, apparently sqlalchemy does not do this automatically.

If I add database = '%s%s%s' % ('"', database, '"') to def remove_database() in operations.py, things are working for me again. Do you know of any way to maybe using configuration tell Sqlalchemy to escape databasenames?

mikeywaites commented 6 years ago

Hey, I'm also seeing this issue with subsequent restore calls.

Traceback (most recent call last):
  File "/usr/local/bin/stellar", line 11, in <module>
    load_entry_point('stellar==0.4.3', 'console_scripts', 'stellar')()
  File "/usr/local/lib/python2.7/site-packages/stellar/command.py", line 279, in main
    stellar()
  File "/usr/local/lib/python2.7/site-packages/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python2.7/site-packages/click/core.py", line 1060, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python2.7/site-packages/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python2.7/site-packages/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python2.7/site-packages/stellar/command.py", line 126, in restore
    app.inline_slave_copy(snapshot)
  File "/usr/local/lib/python2.7/site-packages/stellar/app.py", line 198, in inline_slave_copy
    table.get_table_name('slave')
  File "/usr/local/lib/python2.7/site-packages/stellar/operations.py", line 65, in copy_database
    from_database
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 906, in execute
    return self._execute_text(object, multiparams, params)
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1054, in _execute_text
    statement, parameters
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context
    context)
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception
    exc_info
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", line 200, in raise_from_cause
    reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context
    context)
  File "/usr/local/lib/python2.7/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute
    cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.ProgrammingError) database "stellar_cb87a70f797de380" already exists
 [SQL: '\n                CREATE DATABASE "stellar_cb87a70f797de380" WITH TEMPLATE "stellar_486d7ebb93677a14";\n

I'm sure when testing this earlier in the week i was able to call restore multiple times without any issue :/

Update: re-creating the snapshot and removing the old ones seem to have resolved the issue. Perhaps it's possible that the stellar_data table got in a weird state or something ? Will leave this here in case you want to pick this up.

Update 2: Issue has resurfaced already :/ I'll see if i can find a way to consistently re-produce this error.

kiview commented 5 years ago

I'm seeing the same problem on PostgreSQl 9.6.11 running inside a Docker container.

In my case, this seems to be caused by #62.