Обсуждение: Re: version problem with pg_dump

Brian Kitzberger wrote:
> Steve,
>
> You asked how I built the my install of 8.1.3.  With the tar files at
> the root, I used the gunzip and tar commands from the web site on the
> base, docs, opt, and test tar files as suggested by the PostgreSQL.org
> web site, which made the postgresql-8.1.3 directory.  I then did the
> steps suggested to do the install with slight variation.
>
> ./configure  (I had to use the option --without-readline because it
> gave an error without it)

If you install the readline development files (ie. rpm -i
readline-devel-version.rpm or use YAST or whatever is appropriate for
your distro) then you won't get this error. It basically only affects
command editing and history in psql.

> gmake
> su
> gmake install
> useradd postgres
> mkdir /usr/local/pgsql/data
> chown postgres /usr/local/pgsql/data
> su - postgres
> /usr/local/pgsql/bin/initdb -i -D /usr/local/pgsql/data   (the -i
> options was suggesed)
> /usr/local/pgsql/bin/postmaster -i -D /usr/local/pgsql/data >logfile
> 2>&1 &
> /usr/local/pgsql/bin/psql test
>
> It worked fine.  I was able to create a database from a DDL I wrote and
> do insert into the tables and selects with correct results.  So I was
> testing the pg_dump with I ran into problems.

And had you run /usr/local/pgsql/bin/pg_dump it would have worked fine
as well. But /usr/local/pgsql/bin is probably not in your $PATH at all
let alone existing ahead of /usr/bin so just running pg_dump loaded the
incorrect version.

My quick-n-dirty "fix" is to make symbolic links in /usr/bin for all pg
programs:

cd /usr/local/pgsql/bin
for x in * ; do ln -s /usr/local/pgsql/bin/$x /usr/bin/$x ; done

But be sure to remove the out-of-date version first.

Cheers,
Steve

Steve Crawford <scrawford@pinpointresearch.com> writes:
> Brian Kitzberger wrote:
>> It worked fine.  I was able to create a database from a DDL I wrote and
>> do insert into the tables and selects with correct results.  So I was
>> testing the pg_dump with I ran into problems.

> And had you run /usr/local/pgsql/bin/pg_dump it would have worked fine
> as well. But /usr/local/pgsql/bin is probably not in your $PATH at all
> let alone existing ahead of /usr/bin so just running pg_dump loaded the
> incorrect version.

For that matter, he was presumably running the 7.4 version of psql and
so on, which means that those things also only worked for rather small
values of "work" --- a lot of psql 7.4's backslash commands would likely
fail against an 8.1 server for instance.

> My quick-n-dirty "fix" is to make symbolic links in /usr/bin for all pg
> programs:

The *right* solution if you're using an RPM-based Linux distro is to
grab an RPM distribution of Postgres; trying to make end runs around RPM
is a great way to turn your system into a hopeless mess.

            regards, tom lane

>>My quick-n-dirty "fix" is to make symbolic links in /usr/bin for all pg
>>programs:

But, as I noted, only after you are sure you have removed all vestiges
of the old version. The symbolic links are just a convenience.

> The *right* solution if you're using an RPM-based Linux distro is to
> grab an RPM distribution of Postgres; trying to make end runs around RPM
> is a great way to turn your system into a hopeless mess.

You sure can turn a system into a hopeless mess but I don't agree that I
would only use RPM to install PG - that depends on the situation.

In my case the distros may use RPM as the package manager and RPM is
fine for the base configuration but I am starting with the bare minimum
default installation, hardening/stripping that down some more and then
compiling PG from source. The server has one purpose - running
PostgreSQL as a stand-alone server for clients on the network. Because
of this there are no PG dependent packages installed to start with.

PG is critical to our business and I find that compiling from source
gives me the ability to deploy updates more quickly if necessary and to
customize the options I use to build PG where necessary.

Cheers,
Steve