PG_VERSION Errors???
I have just installed the latest non-beta version of Postgres on a RedHat
6.0 server.
I get the following messages on the console:
No data directory -- can't proceed.
-bash: 1:command not found
-bash: 1:command not found
INIT: Id "pg" respawning to fast: disabled for 5 minutes
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.
Joseph J. Glerum
Systems Support Technician
Ky Division of Emergency Management
(502) 607-1690
jglerum@kydes.dma.state.ky.us
http://webserve.dma.state.ky.us
"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
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:
Show quoted text
"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
"Walter M. Yuan" wrote:
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.
Yes, this can sometimes be a real problem. Although I've not had it
reported very often -- and for the 6.5.x to 7.0 transition, we'll be
able to use pg_upgrade (yay!). This causes problems with everybody --
and I'm so glad it is fixed for 7.0.
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.
The executables are precompiled in the postgresql-test RPM. Simply cd
to /usr/lib/pgsql/test/regress, su to postgres, make sure postmaster is
running, and './regress.sh platform' Make is not required to run
regression in the RPM distribution.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-> I have just installed the latest non-beta version of Postgres on a RedHat
-> 6.0 server.
->
-> I get the following messages on the console:
->
->
-> No data directory -- can't proceed.
-> -bash: 1:command not found
-> -bash: 1:command not found
-> INIT: Id "pg" respawning to fast: disabled for 5 minutes
-> 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.
Why are you e-mailing so many lists??
If you watch the 'initdb' command carefully, you'll note a 'pg_version'
error. Find 'pg_version' under the source build, then run
pg_version /usr/local/pgsql/data
--titus