Re: [GENERAL] re-instalation
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] re-instalation |
Дата | |
Msg-id | 4008.980024984@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [GENERAL] re-instalation
|
Список | pgsql-hackers |
"Brett W. McCoy" <bmccoy@chapelperilous.net> writes: > On Sat, 20 Jan 2001, Martin A. Marques wrote: >> The problem was that the server got downgraded from Solaris 8 to Solaris 7 >> and the binaries didn't work, so I recompiled. There was no way of using >> pg_dump because I couldn't get the postmaster up. > The problem with just moving your database to the new location is that > there are location dependencies built into it when you use initdb to > initialize it, so it's not reliable. AFAIK, there are *not* any location dependencies in a standard PG database (other than path names associated with alternate database locations, if you are so foolish as to use hard-wired alternate-location pathnames). So in theory Martin should have been able to tar up the entire $PGDATA tree and move it somewhere else. I'm not sure why he's reporting a problem, but I don't think that's it. A more plausible line of thought is that there is some environmental difference between the old and new setup --- perhaps PG was compiled with different options (with/without locale or multibyte support), or is being run under a different LOCALE environment, etc. I'm not sure exactly why that sort of thing would manifest itself as re-appearance of tables that had been deleted in the old setup, but that's my bet. Before you write this off as unreasonable, consider that changing locales renders indexes on text columns effectively corrupt, if there are any entries whose sort order changes in the new locale. I don't quite see the chain of events from corrupt indexes on pg_class to unexpected table entries, but it doesn't seem as unlikely as blaming the problem on a physical move of the database directory tree. regards, tom lane
В списке pgsql-hackers по дате отправления: