Обсуждение: 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: > "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