I wonder if your functions will fail as well. Will vacuum or statistics recompiles all the stored procedures and functions? Google didn't show me any more information on this one.
I remember in Sybase, changing the statistics on a table too much used to reek havoc, slowing queries down by over 50x. Used to have to "EXEC myProcedure WITH RECOMPILE" to tell the query optimizer to use the latest statistics. Also used to rebuild the statistics every night. But I think this is already done by Postgres. FWIW/ Keenan On Monday, January 21, 2013 at 4:59 PM, Nickolay Kolev wrote: > The crazy idea works! It was indeed because of prepared statements. > > I will look into why prepared statements do not work after a table is dropped > and recreated. Should be in postgresql_adapter.rb somewhere. > > Pulling the carpet under Rails' feet and putting it back exactly as it was > before (identical table names) should not cause prepared statements to fail, > unless they checksum the tables by something other than their names in some > way. > > Thanks a lot for the hint, Peter! > > On Monday, January 21, 2013 10:08:25 PM UTC+1, Peter van Hardenberg wrote: > > 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 > > (javascript:)> 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 <nmk...@gmail.com > > > (javascript:)> 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+un...@googlegroups.com (javascript:) > > > > 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 > (mailto: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
