Re: upgrade broke stuff, downgrade still broke

From: will trillich <will(at)serensoft(dot)com>
To: Joseph Shraibman <jks(at)selectacast(dot)net>, pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: upgrade broke stuff, downgrade still broke
Date: 2001-02-27 23:45:34
Message-ID: 3A9C3C14.D2B9786C@serensoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Joseph Shraibman wrote:
>
> The data files aren't compatible, so I'm surprised it worked at all. I
> thought postgres would look for a version number in the data directory
> and refuse to run if it didn't match.

i'd agree if the sequence was brain-dead:
1) zap old binaries.
2) install new binaries.
3) pray a lot.
4) see if you can read the old data with the new binaries.

but why wouldn't the install be intelligent, like:
1) use existing binaries to dump schema and data
2) shelve/archive current binaries
3) install new binaries.
4) restore structure and content from dump...

if there are major alterations between versions, there might
be snags -- using oids in a strange manner, relying on a
trigger feature that's nonexistent in the current iteration,
using stored procedures to do obscure things... but my data
was really simple tables, views and indexes. (one sequence,
period.) no triggers, no rules, no procedures.

some populated tables are just fine, others are missing
completely; some views became empty tables.

ls /var/lib/postgresql/data/base/puz shows that the files
i'm looking for do exist, and have nonzero size (and haven't
been modified, so maybe they're still copacetic). any ideas
on breathing life into them?

(i've been following the 'vacuum/backup' thread so this won't
bit me in the ass next time... :) )

--
mailto:will(at)serensoft(dot)com
http://www.dontUthink.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message will trillich 2001-02-28 00:09:03 joining databases
Previous Message Limin Liu 2001-02-27 23:40:30 Is this a bug?