So I was forced to re-do the migration since we had to prepare for a power outage anyway. Upon re-running the command, I found out that the reason I was receiving the notices in STDERR was due to the the long string of ordered schemas in my search path. It had a "SET search_path TO public, x, y, z, ..." at the beginning of the file and of course schemas x, y, z, etc hadn't been created yet. So there's no real cause for alarm after all. On Fri, Apr 15, 2011 at 10:23 AM, Adrian Klaver <adrian.klaver@xxxxxxxxx> wrote: > On Friday, April 15, 2011 7:10:00 am Shawn Gennaria wrote: > >> >> Yes, it's running as a postgres superuser. Unfortunately I didn't >> dump the output to a file so I could read it after it exceeds the >> terminal's buffer. >> >> It just dawned on me that I may have misinterpreted the messages. I >> just took a look through the early parts of the file I'm using to >> restore everything and noticed that many of my stored functions >> contain references to other stored functions. Naturally, one wouldn't >> be able to create a function unless all dependent referenced functions >> were created first. It would be rather time-consuming to sort that >> out manually and re-add each function in the correct order. Does >> anyone have experience working that out with some kind of tool? Does >> postgres have anything built-in to help with this? > > > So do the schemas exist in the 9.0.3 database? > As you stated there are dependency issues but I have not seen that be a problem. > The error messages you saw are not unusual and are probably more of the > informative kind, not the fatal kind. I don't suppose you had logging turned on > in the 9.0.3 server when you did the restore? > >> No modifications were made to the 8.4 cluster after I put the pgdata >> folder back in place. All I did was quickly login with PgAdmin to >> verify that it wasn't completely empty and then I logged out. I >> wasn't thorough about it and didn't even run a query. I do have logs >> in my pgdata/pg_log folder from each day. Would those help track down >> issues with getting the server to start, or are they only used once >> the server's already up? I took a look through the recent ones, and >> the only thing that looks odd from that time period are repeating >> messages: > > There some parts of the server start that may not make it into the logs but most > does, so yes they would be useful. > >> >> FATAL: unrecognized configuration parameter "application_name" > > Have you looked in postgresql.conf or pg_hba.conf to see if the above is there? > >> >> In either case, the issue seems to have worked itself out after the >> server was rebooted. >> >> >> Thanks! >> >> sg >> > >> > -- >> > Adrian Klaver >> > adrian.klaver@xxxxxxxxx > > -- > Adrian Klaver > adrian.klaver@xxxxxxxxx > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
