HI, Lamar,
A quick question on the "dump/initdb/restore" cycle: I don't think that it
works that well, at least from my recent experience. With just a small db
(approx 2MB of dumped size), I failed to use restore as it ran out of
query buffer. Instead, I had to import the schemas first and then load
each table (or sub-table) separately. Quite few people suggested me to use
either pg_lo or upgrade to the beta-7.0 (where query length is no longer
limited to 2 block-size)... I just want to confirm w/ you on this, thanks.
btw, for the regression test, I can't find the makefile.global which is
required to compile the executables. Did I miss sth? Thanks again.
Regards,
Walter
Walter M. Yuan-- CASSEL, Dept. of Econ.
Bunche Hall, UCLA,
Los Angeles, CA 90095
(CIT) :626-395-8091; (UCLA):310-206-7466
On Mon, 3 Apr 2000, Lamar Owen wrote:
> "Glerum, Joe - KyEM" wrote:
> > Database system in directory /usr/local/pgsql/data is not compatable
> > with this version of Postgres, or we are unable to read the PG_VERSION file.
> > Explanation from the ValidatePgVersion: Version number in file
> > '/usr/local/pgsql/data/PG_VERSION' should be 6.5, not 6.4.
>
> > When I change the 6.4 to 6.5 and restart the postmaster I can't do so with
> > errors to change it back to 6.4.
>
> Did you do a dump/initdb/restore cycle? For a major version upgrade
> (such s 6.4.2 to 6.5.3), you must first dump your old database using
> pg_dumpall, clear out the database directory, initdb with the new
> version, then restore using 'psql -e template1 <dumped-data-file'.
>
> By the error message you gave, I'm assuming you are using the standard,
> non-RPM distribution. The RPM distribution since 6.5.1 or so has
> included a set of tools to make the migration easier. Upon an upgrade
> of the RPM's, a copy of the old executables is saved; also, a
> postgresql-dump utility is provided to use the old executables to make a
> dump. Then, the new version can be started up.
>
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>