Thanks for the extra reply Nickolay. I think I came up with a pretty minimal test-case based on your example.
On Mon, Jan 21, 2013 at 10:18 PM, Nickolay Kolev <[email protected]> wrote: > I looked at the thread at pgsql-hackers. It seems that Tom Lane overlooked > the dump/restore part. > > A picture is worth a thousand words: > > http://grozdova.com/psql-missing-relation-after-dump-restore.png > > I am not sure if this is intended behaviour or not, but it should become > clear at the thread there. > > > On Tuesday, January 22, 2013 12:30:44 AM UTC+1, Peter van Hardenberg wrote: > >> 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 <[email protected]>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 >>> <[email protected]>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 <[email protected]>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+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+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 > [email protected] > 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 [email protected] For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
