So here's the deal - when you prepare a statement, Postgres compiles it down internally for performance. This means that it doesn't target the table by name anymore, but by it's internal "OID". This guarantees nice properties like query stability, but apparently doesn't play well with schema changes. One could argue that this is a Postgres bug or defect, but it could definitely be worked around in Rails.
I've opened a thread on the pgsql-hackers list about this issue, but it's not terribly likely it will make the 9.3 release nor is it so dire as to warrant a point release, so the world will likely have to live with this defect for another 18 months at least. -p On Mon, Jan 21, 2013 at 2:20 PM, Keenan Brock <kee...@thebrocks.net> wrote: > 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>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> 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 > For more options, visit this group at > http://groups.google.com/**group/heroku?hl=en_US?hl=en<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 > > > -- > 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
