Обсуждение: Convert v7.0.2-2c1 DB
I have a client with a v7.0.2-2c1 database stored on media. The database files were stored raw, not dumped. Their current pgsql version is 7.1; they do not have v7.0.2-2c1 installed anywhere. Can I update/add their old db into their new system without installing v7.0.2-2c1 onto another system to do a dump? If I have to install v7.0.2-2c1, where is it? I haven't been able to find it on the mirrors. I assume "c1" means it was a release candidate. TIA! -- Patrick S. Riedel ANALYTICAL SERVICES, LLC 970.481.1963
On Tue, 2003-02-11 at 17:27, Patrick S. Riedel wrote: > I have a client with a v7.0.2-2c1 database stored on media. The > database files were stored raw, not dumped. Their current pgsql version > is 7.1; they do not have v7.0.2-2c1 installed anywhere. > > Can I update/add their old db into their new system without installing > v7.0.2-2c1 onto another system to do a dump? > > If I have to install v7.0.2-2c1, where is it? I haven't been able to > find it on the mirrors. I assume "c1" means it was a release candidate. > > Lordy, that's a fine mess you've got there. I'm fairly certain that it wont work if you try to run 7.1.x on top of it. You best bet is to install a 7.0.x somewhere and then try to copy the data files to that installation. If you can get that working, install a newer version (7.3.2?) and do a dump out of the 7.0.x database and see what happens. As far as what version of 7.0.x to use, I don't recognize that release so it could very well be a release candidate version, but might also be a vendor/rpm/debian style version tag. Unless one of the developers comes forward and happens to have a copy of it, I would grab the 7.0.2 release from the ftp server and try that first. If it doesn't work, try 7.0.1, then 7.0.3. (Note there is a 7_0_patches tag in cvs, you could try to use that though i suspect thats closer to 7.0.3 than 7.0.2, and I don't know how much faith I have in the CVS tags from 2 years ago.) In any/all cases, always copy the data over, never do anything on the original files. Robert Treat
Robert Treat <xzilla@users.sourceforge.net> writes:
> On Tue, 2003-02-11 at 17:27, Patrick S. Riedel wrote:
>> I have a client with a v7.0.2-2c1 database stored on media. The
>> database files were stored raw, not dumped. Their current pgsql version
>> is 7.1; they do not have v7.0.2-2c1 installed anywhere.
> Lordy, that's a fine mess you've got there.
Yup...
> As far as what version of 7.0.x to use, I don't recognize that release
> so it could very well be a release candidate version, but might also be
> a vendor/rpm/debian style version tag.
Any released 7.0.* version should be disk-level-compatible. Given that
this is a 7.0.2-something and not a 7.0-something I don't think you need
to worry that it might be a 7.0 prerelease. So as long as you have the
complete $PGDATA directory tree (not a subset that omits pg_log, for
example) I think you should be able to compile any 7.0.* release and
fire it up against that directory tree. Then pg_dump and away you go.
> In any/all cases, always copy the data over, never do anything on the
> original files.
Check, always keep a pristine copy until you *know* you have a working,
cross-checked, backed-up database in a later version...
regards, tom lane
On Tue, 2003-02-11 at 23:11, Tom Lane wrote: > Robert Treat <xzilla@users.sourceforge.net> writes: > > On Tue, 2003-02-11 at 17:27, Patrick S. Riedel wrote: > >> I have a client with a v7.0.2-2c1 database stored on media. The > >> database files were stored raw, not dumped. Their current pgsql version > >> is 7.1; they do not have v7.0.2-2c1 installed anywhere. > > > Lordy, that's a fine mess you've got there. > > Yup... > > > As far as what version of 7.0.x to use, I don't recognize that release > > so it could very well be a release candidate version, but might also be > > a vendor/rpm/debian style version tag. > > Any released 7.0.* version should be disk-level-compatible. Given that > this is a 7.0.2-something and not a 7.0-something I don't think you need > to worry that it might be a 7.0 prerelease. So as long as you have the > complete $PGDATA directory tree (not a subset that omits pg_log, for > example) I think you should be able to compile any 7.0.* release and > fire it up against that directory tree. Then pg_dump and away you go. > > > In any/all cases, always copy the data over, never do anything on the > > original files. > > Check, always keep a pristine copy until you *know* you have a working, > cross-checked, backed-up database in a later version... > > regards, tom lane Thanks for the replies! I was able to find ye ol' v7.0.2-2c1 and installed on a test machine. Dumped db, all is well. -- Patrick S. Riedel ANALYTICAL SERVICES, LLC 970.481.1963