"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
