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