crazy idea: try disabling prepared statements. rationale: you might have prepared statements enabled, which is the default, which would mean that instead of targeting the table by name it would be compiled into an internal object ID which would change when you run the restore since it drops and recreates the tables.
On Mon, Jan 21, 2013 at 1:06 PM, Peter van Hardenberg <p...@heroku.com>wrote: > pgbackups makes completely standard dumps, but you could use a local > pg_dump to prove equivalency. Doing a restore sounds like it's dropping and > recreating all the tables. Perhaps there's some kind of magic that makes > the migrations work which doesn't get triggered in your dump/restore case. > > > On Mon, Jan 21, 2013 at 11:44 AM, Nickolay Kolev <nmko...@gmail.com>wrote: > >> I don't think this is it. Even if there are no schema changes, the same >> behaviour can be observed. Actually Rails *will* pick up schema changes >> (e.g. as introduced by migrations) when running in development mode. >> >> I have only seen this with Postgres and only when loading a dump. If true >> for all dumps or only the ones created by pgbackups I am not sure. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Heroku" group. >> >> To unsubscribe from this group, send email to >> heroku+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/heroku?hl=en_US?hl=en >> > > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
