Thread: Convert v7.0.2-2c1 DB

Convert v7.0.2-2c1 DB

From
"Patrick S. Riedel"
Date:
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


Re: Convert v7.0.2-2c1 DB

From
Robert Treat
Date:
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



Re: Convert v7.0.2-2c1 DB

From
Tom Lane
Date:
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

Re: Convert v7.0.2-2c1 DB

From
"Patrick S. Riedel"
Date:
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