Re: Installation trouble -- oops

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: pgsql general list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Installation trouble -- oops
Date: 2005-10-30 03:20:34
Message-ID: 200510292020.34682.scrawford@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday 28 October 2005 19:18, you wrote:
> Try:
>
> /usr/local/pgsql/bin/initdb --no-locale -D /var/lib/pgsql/data

OK. That works (even without the --no-locale). Which makes me puzzled
and worried.The initdb I used and the one I used earlier are
identical (as verified by the fact that I copied the binaries
from /usr/local/pgsql/bin to /usr/bin and by checking with diff and
by searching the entire drive for all versions of the PG binaries -
checks shown below).

Is postgresql (or some parts thereof) now using relative pathing and
has that behavior changed? I don't recall having this problem in the
past. Running /usr/bin/pg_config --bindir returns /usr/bin
while /usr/local/pgslq/bin/pg_config --bindir
returns /usr/local/pgsql/bin even though the two binaries are
identical.

Looks like the lesson is that if you want the programs in /usr/bin,
use symbolic links rather than cp.

Cheers,
Steve

for x in * ; do md5sum /usr/local/pgsql/bin/$x /usr//bin/$x ; done
c9bf803d2ee9960d7435fff80ec35737 /usr/local/pgsql/bin/clusterdb
c9bf803d2ee9960d7435fff80ec35737 /usr//bin/clusterdb
cb62a668ffa7048907d03a6432498424 /usr/local/pgsql/bin/createdb
cb62a668ffa7048907d03a6432498424 /usr//bin/createdb
b9acda85ac4797ecd8b4d1de4949e9fa /usr/local/pgsql/bin/createlang
b9acda85ac4797ecd8b4d1de4949e9fa /usr//bin/createlang
3329c93c9bda413b89dfe2c717624cf3 /usr/local/pgsql/bin/createuser
3329c93c9bda413b89dfe2c717624cf3 /usr//bin/createuser
d22022dd17c80867b8ff14efbd576c91 /usr/local/pgsql/bin/dropdb
d22022dd17c80867b8ff14efbd576c91 /usr//bin/dropdb
675ce5ebbdf3b9bec3a96bd3040e3d4e /usr/local/pgsql/bin/droplang
675ce5ebbdf3b9bec3a96bd3040e3d4e /usr//bin/droplang
a9cc5a285245332504aeae230df3aa21 /usr/local/pgsql/bin/dropuser
a9cc5a285245332504aeae230df3aa21 /usr//bin/dropuser
ce18d494254b3e003fe08f8e73041bc0 /usr/local/pgsql/bin/ecpg
ce18d494254b3e003fe08f8e73041bc0 /usr//bin/ecpg
691f1c766d54b8a535936fbdb9591c92 /usr/local/pgsql/bin/initdb
691f1c766d54b8a535936fbdb9591c92 /usr//bin/initdb
eda7372ae2a01504da905b3706ce70b9 /usr/local/pgsql/bin/ipcclean
eda7372ae2a01504da905b3706ce70b9 /usr//bin/ipcclean
7682bd875fcf3c5b57d5e89bc3f57213 /usr/local/pgsql/bin/pg_config
7682bd875fcf3c5b57d5e89bc3f57213 /usr//bin/pg_config
72bb7c22ff14ef9f8dfe140cdcd9341f /usr/local/pgsql/bin/pg_controldata
72bb7c22ff14ef9f8dfe140cdcd9341f /usr//bin/pg_controldata
7549b3387bdef3022c63bc0c19098a8a /usr/local/pgsql/bin/pg_ctl
7549b3387bdef3022c63bc0c19098a8a /usr//bin/pg_ctl
6c1134ba9bbb195a1ff3ad65fcc98917 /usr/local/pgsql/bin/pg_dump
6c1134ba9bbb195a1ff3ad65fcc98917 /usr//bin/pg_dump
53c9d9fccd5d466a0976cddbec68b85c /usr/local/pgsql/bin/pg_dumpall
53c9d9fccd5d466a0976cddbec68b85c /usr//bin/pg_dumpall
6da2da5460ee64301bdbabd7ba210962 /usr/local/pgsql/bin/pg_resetxlog
6da2da5460ee64301bdbabd7ba210962 /usr//bin/pg_resetxlog
178c671867afe5483c1127a7db073955 /usr/local/pgsql/bin/pg_restore
178c671867afe5483c1127a7db073955 /usr//bin/pg_restore
b64c8fa49fca11cf1340fdee6e67a75c /usr/local/pgsql/bin/postgres
b64c8fa49fca11cf1340fdee6e67a75c /usr//bin/postgres
b64c8fa49fca11cf1340fdee6e67a75c /usr/local/pgsql/bin/postmaster
b64c8fa49fca11cf1340fdee6e67a75c /usr//bin/postmaster
cc59b501ec66f39c07ea6a5862dda6dc /usr/local/pgsql/bin/psql
cc59b501ec66f39c07ea6a5862dda6dc /usr//bin/psql
d4abcd0d876d16f38ba5fc76d4f7de64 /usr/local/pgsql/bin/vacuumdb
d4abcd0d876d16f38ba5fc76d4f7de64 /usr//bin/vacuumdb

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew Peter 2005-10-30 03:39:23 function example?
Previous Message J French 2005-10-30 00:54:01 Re: Generating an ANSI compliant schema recreation script