Re: version problem with pg_dump

"Brian Kitzberger" <KITZBERGERB@mail.co.stanislaus.ca.us> writes:

which pg_dump returned /usr/bin/pg_dump
which pg_dumpall returned /usr/bin/pg_dump
which psql returned /usr/bin/psql

Didn't you say that you had installed PG 8.1.3 in a separate directory
tree (something about postgresql-8.1.3)? Maybe your problem is not
having changed your PATH to find those files before the default ones
in /usr/bin.

I have never installed any other version than 8.1.3.

No, but 7.4.8 very possibly could have come with your OS.

regards, tom lane

Brian Kitzberger wrote:

Hi Steve,

pg_dump --version returned 7.4.8
pg_dumpall --version returned 7.4.8
psql *version returned 7.4.8
which pg_dump returned /usr/bin/pg_dump
which pg_dumpall returned /usr/bin/pg_dump
which psql returned /usr/bin/psql

To find the file I used from the root
find . -name pg_dump

It would be unusual for the files to be in those locations if you did
the usual "./configure ; make ; make install". How, exactly, did you
install PostgreSQL?

As Scott suggested, try running "rpm -qa | grep -i postgres" (assuming
rpm is at the core of your package management) and when you find that it
was already installed, use rpm to erase it.

Here, things can get interesting. While you may not have intentionally
installed PostgreSQL, your package manager may have installed it for you
to solve a dependency (PHP with PG support or some app that requires PG
for example) you may find your package manager complaining about
dependencies when you try to remove it. But worry about burning that
bridge when you get to it.

Cheers,
Steve

Steve,

Okay, not only am I new to PostgreSQL but I am new to Linux with a
little experience years ago with Unix. So I didn't know about rpm nor
does any one else here. But anyway, the result of running rpm is:

postgresql-libs-7.4.8-0.6
postgresql-server-7.4.8-0.6
postgresql-jdbc-7.3-189.1
postgresql-7.4.8-0.6
qt3-postgresql-3.3.1-35.11

I did an ls in the /usr/bin directory and sure enough there are the
other files I could not find before. So I guess I will have to cross
the bridge. As a test, I just mv the file /usr/bin/pg_dump. If rpm had
a dependence on that file would it cause some kind of error message in
trying to move it? I was able to successfully move the file to the
root.

Brian

Steve Crawford <scrawford@pinpointresearch.com> 3/23/2006 12:50 PM

Brian Kitzberger wrote:

Hi Steve,

pg_dump --version returned 7.4.8
pg_dumpall --version returned 7.4.8
psql *version returned 7.4.8
which pg_dump returned /usr/bin/pg_dump
which pg_dumpall returned /usr/bin/pg_dump
which psql returned /usr/bin/psql

To find the file I used from the root
find . -name pg_dump

It would be unusual for the files to be in those locations if you did
the usual "./configure ; make ; make install". How, exactly, did you
install PostgreSQL?

As Scott suggested, try running "rpm -qa | grep -i postgres" (assuming

rpm is at the core of your package management) and when you find that
it
was already installed, use rpm to erase it.

Here, things can get interesting. While you may not have intentionally

installed PostgreSQL, your package manager may have installed it for
you
to solve a dependency (PHP with PG support or some app that requires PG

for example) you may find your package manager complaining about
dependencies when you try to remove it. But worry about burning that
bridge when you get to it.

Cheers,
Steve

On March 23, 2006 01:32 pm, "Brian Kitzberger"
<KITZBERGERB@mail.co.stanislaus.ca.us> wrote:

Steve,

Okay, not only am I new to PostgreSQL but I am new to Linux with a
little experience years ago with Unix. So I didn't know about rpm nor
does any one else here. But anyway, the result of running rpm is:

postgresql-libs-7.4.8-0.6
postgresql-server-7.4.8-0.6
postgresql-jdbc-7.3-189.1
postgresql-7.4.8-0.6
qt3-postgresql-3.3.1-35.11

I did an ls in the /usr/bin directory and sure enough there are the
other files I could not find before. So I guess I will have to cross
the bridge. As a test, I just mv the file /usr/bin/pg_dump. If rpm had
a dependence on that file would it cause some kind of error message in
trying to move it? I was able to successfully move the file to the
root.

RPM won't say anything unless you run rpm commands (ie. rpm -e package to
remove it).

The only one of those you're likely to have a dependency problem with is
postgresql-libs. perl-DBD-Pg, and possibly a few other packages (like PHP,
as a previous poster mentioned), will be linked to that.

--
Alan

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)
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.

Brian

Steve Crawford <scrawford@pinpointresearch.com> 3/23/2006 12:50 PM

Brian Kitzberger wrote:

Hi Steve,

pg_dump --version returned 7.4.8
pg_dumpall --version returned 7.4.8
psql *version returned 7.4.8
which pg_dump returned /usr/bin/pg_dump
which pg_dumpall returned /usr/bin/pg_dump
which psql returned /usr/bin/psql

To find the file I used from the root
find . -name pg_dump

It would be unusual for the files to be in those locations if you did
the usual "./configure ; make ; make install". How, exactly, did you
install PostgreSQL?

As Scott suggested, try running "rpm -qa | grep -i postgres" (assuming

rpm is at the core of your package management) and when you find that
it
was already installed, use rpm to erase it.

Here, things can get interesting. While you may not have intentionally

installed PostgreSQL, your package manager may have installed it for
you
to solve a dependency (PHP with PG support or some app that requires PG

for example) you may find your package manager complaining about
dependencies when you try to remove it. But worry about burning that
bridge when you get to it.

Cheers,
Steve

On Thu, 2006-03-23 at 15:32, Brian Kitzberger wrote:

Steve,

Okay, not only am I new to PostgreSQL but I am new to Linux with a
little experience years ago with Unix. So I didn't know about rpm nor
does any one else here. But anyway, the result of running rpm is:

Hey, we all started somewhere. Welcome to the club, eh?

postgresql-libs-7.4.8-0.6
postgresql-server-7.4.8-0.6
postgresql-jdbc-7.3-189.1
postgresql-7.4.8-0.6
qt3-postgresql-3.3.1-35.11

I did an ls in the /usr/bin directory and sure enough there are the
other files I could not find before. So I guess I will have to cross
the bridge. As a test, I just mv the file /usr/bin/pg_dump. If rpm had
a dependence on that file would it cause some kind of error message in
trying to move it? I was able to successfully move the file to the
root.

Nah, RPM won't stop you doing things like that. It will, however, let
you know files are missing if you know the commands to throw at it.

Take a look here:

http://www.rpm.org/

Also, if you're gonna be using linux and postgresql, I'd recommending
downloading and installing some fairly recent versions of each. For
linux distros, there are hundreds of choices. Fedora Core 5 just came
out, but 4 is much more stabilized now. Debian, Suse, Ubuntu are all
good distros. You can get RedHat Enterprise clones called "white box
linux" or "centos" which are basically exactly the same with different
names inside them.

Then you can just install postgresql with the yum package manager
manager with a command like:

yum install postgres*

and that's it.

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