Bug 158100 - psql abends with undefined relocation symbol
psql abends with undefined relocation symbol
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rh-postgresql (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2005-05-18 13:42 EDT by Douglas Campbell
Modified: 2013-07-02 23:05 EDT (History)
1 user (show)

See Also:
Fixed In Version: rh-postgresql-7.3.10-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-28 12:42:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Douglas Campbell 2005-05-18 13:42:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2

Description of problem:
When I enter "psql spamflambeau -U postgres", the application terminates immediately after printing what are apparently two error messages:

[root@warthog root]# psql spamflambeau -U postgres
ERROR:  parser: syntax error at or near "."
Welcome to psql 7.3.9-RH, the PostgreSQL interactive terminal.
Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help on internal slash commands
       \g or terminate with semicolon to execute query
       \q to quit
psql: relocation error: psql: undefined symbol: PQgetssl

In my case, the password contains a period.  Applications using the same password are otherwise able to connect to the database and interoperate.

Entering an incorrect password not containing a period gets the following apparently correct behavior:

[root@warthog root]#  psql spamflambeau -U postgres
psql: FATAL 1:  Password authentication failed for user "postgres"

Problem appeared after I applied service rh-postgresql-7.3.9-2 via download by up2date followed by "rpm -Uvh rh-post*7.3.9-2*.rpm".  The update completed successfully; the system has not been rebooted.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install redhat linux AS 3
2.Apply all errata except squirrelmail 1.4.3a and rh-postgresql
3.Apply rh-postgresql-7.3.9-2; do not apply squirrelmail
4.Attempt to connect to existing database using psql and password containing a period.

Actual Results:  See description above.

Expected Results:  Successful connection and ability to enter SQL commands and psql control commands.

Additional info:

Results of ls on psql

[root@warthog root]# which psql
[root@warthog root]# ls -al /usr/bin/psql
-rwxr-xr-x    1 root     root       136692 Feb  8 12:53 /usr/bin/psql
[root@warthog init.d]# ls -al /etc/init.d/rhdb
-rwxr-xr-x    1 root     root         6873 Feb  8 12:53 /etc/init.d/rhdb
[root@warthog init.d]# cd /usr/lib
[root@warthog lib]# ls -al *psq*
lrwxrwxrwx    1 root     root           20 May 31  2004 libodbcpsql.so -> libodbcpsql.so.2.0.0
lrwxrwxrwx    1 root     root           20 May 31  2004 libodbcpsql.so.1 -> libodbcpsql.so.1.0.0
-rwxr-xr-x    1 root     root       212552 May  8  2004 libodbcpsql.so.1.0.0
lrwxrwxrwx    1 root     root           20 May 31  2004 libodbcpsql.so.2 -> libodbcpsql.so.2.0.0
-rwxr-xr-x    1 root     root       223336 May  8  2004 libodbcpsql.so.2.0.0
lrwxrwxrwx    1 root     root           21 May 31  2004 libodbcpsqlS.so -> libodbcpsqlS.so.1.0.0
lrwxrwxrwx    1 root     root           21 May 31  2004 libodbcpsqlS.so.1 -> libodbcpsqlS.so.1.0.0
-rwxr-xr-x    1 root     root         6032 May  8  2004 libodbcpsqlS.so.1.0.0
lrwxrwxrwx    1 root     root           19 Jan 12 03:38 libpsqlodbc.so -> libpsqlodbc.so.0.27
lrwxrwxrwx    1 root     root           19 Jan 12 03:38 libpsqlodbc.so.0 -> libpsqlodbc.so.0.27
-rwxr-xr-x    1 root     root       196348 Oct 24  2004 libpsqlodbc.so.0.27
Comment 1 Douglas Campbell 2005-05-18 13:46:44 EDT
Maybe my fault?  Just did /etc/init.d/rhdb restart:

[root@warthog pgsql]# /etc/init.d/rhdb restart
Stopping PostgreSQL - Red Hat Edition service:             [  OK  ]
An old version of the database format was found.\nYou need to upgrade the data
format before using PostgreSQL.\nSee (Your System's documentation
directory)/rh-postgresql-7.3/README.rpm-dist for more information.

Hoo boy.  This is going to be painful.
Comment 2 Douglas Campbell 2005-05-18 13:53:16 EDT
No documentation on need to rebuild databases or how to rebuild databases found in
Comment 3 Douglas Campbell 2005-05-18 14:22:17 EDT
PG_VERSION was 7.2; downgraded to 7.2.6 and restored operation.  Will db_dumpall
and then retry the upgrade.  Note:  Was unable to extract database schemas etc
because postmaster was not running (and would not run).
Comment 4 Tom Lane 2005-05-18 15:30:48 EDT
Which rh-postgresql RPMs did you install exactly?  The PQgetssl failure seems to
indicate that you still had a non-SSL-capable libpq.so, which I think could only
happen if you'd not installed rh-postgresql-libs.  It does look like the RPM
specfile is missing a dependency: it should have been set up to compel you to
include the -libs RPM in the update.

But in any case, your real problem is that you seem to be trying to overwrite a
PG 7.2 installation with PG 7.3; which you can't do without advance preparation,
ie dumping the old database.  Where did the 7.2 installation come from?  We
certainly never shipped that PG version with RHEL3.
Comment 5 Douglas Campbell 2005-05-18 19:45:24 EDT
You are correct -- the RHEL3 system was upgraded from RH8.0.  I kept the older
database system (which obviously was not rh-postgresql) until I could migrate
the database, and then forgot to migrate.  When the rh-postgresql rpms showed up
on up2date, I blindly downloaded all of them and then did an rpm -Uvh.  They all
installed successfully without any warnings.  Note that I did not shut down my
older 7.2 postgres server, but then tried to run psql to access and maintain the
old database.  So we have the situation where psql is supposedly updated, but
the postmaster it is trying to access is not.

I then restarted postmaster, and all hell broke loose.  The server was rightly
heartbroken over having to deal with 7.2 data and refused to come up.  If the
server won't come up, I can't do pg_dumpall or anything else.  I have dropped
back to the older (nonstandard) postmaster and everything is working.  My plan
is to do pg_dumpall on my databases tonight, upgrade to rh-postgresql, and
reload the databases.

There are some wierdnesses associated with the psql though that bear looking at;
for example, are passwords with periods now verbotten?  Why would the SSL
library not install or not be accessible from psql if I upgrade to rh-postgresql?  

You are welcome to close this with a pilot error definition -- later tonight
I'll have a more definitive word on what happened after I do the
dump/stop/7.2uninstall/7.3install/start/reload.  By the way, you aren't the JPEG
Thomas Lane, are you?
Comment 6 Tom Lane 2005-05-18 23:56:40 EDT
As best I can tell, the issue is that you still had a 7.2 version of libpq.so that had been built without SSL 
support.  The rh-postgresql RPM contains a version of /usr/bin/psql that was built with SSL enabled 
and therefore requires an SSL-enabled libpq.so.  I can see how this failure would occur if you'd missed 
including the rh-postgresql-libs RPM in your update --- can you confirm that you did or did not have 
that installed?  It's definitely a bug in the rh-postgresql base RPM that it will allow itself to be installed 
without installing rh-postgresql-libs at the same time, but I'm not quite sure yet whether there is 
another issue beyond that.

I'm pretty certain that dots in the password are not relevant.

Yeah, I've heard of JPEG before ;-)
Comment 7 Douglas Campbell 2005-05-19 03:17:31 EDT
Note the dates on the pgsql executable and the rhdb initialization script.  Here
are the dates for the 7.2 version I've got currently:

 [root@warthog root]# ls -al /usr/bin/psql
-rwxr-xr-x    1 root     root       119936 Oct 24  2004 /usr/bin/psql
[root@warthog root]# ls -al /etc/init.d/rhdb
ls: /etc/init.d/rhdb: No such file or directory
[root@warthog root]# ls -al /etc/init.d/postgresql
-rwx------    1 root     root         6370 Oct 24  2004 /etc/init.d/postgresql

As you can see, the psql with the SSL problem comes with rh-postgresql-7.3.9, as
the date (8 Feb 2005) matches the init.d script for rhdb.  Hence the problem is
occurring at a lower level, perhaps with the shared objects.

It looks like I have the libs:

[root@warthog root]# cd /var/spool/up2date
[root@warthog up2date]# ls -al rh-post*.rpm
-rw-r--r--    1 root     root      1672484 Feb 20 18:32
-rw-r--r--    1 root     root     15587353 Feb 20 18:33
-rw-r--r--    1 root     root       760395 Feb 20 18:33
-rw-r--r--    1 root     root      4649762 Feb 20 18:33
-rw-r--r--    1 root     root       193025 Feb 20 18:33
-rw-r--r--    1 root     root        92484 Feb 20 18:33
-rw-r--r--    1 root     root        45356 Feb 20 18:33
-rw-r--r--    1 root     root      2636344 Feb 20 18:33
-rw-r--r--    1 root     root        28459 Feb 20 18:33
-rw-r--r--    1 root     root      1184689 Feb 20 18:34

I can't confirm install of the libs, because I manually did rpm -Uvh
rh-post*.rpm; I have up2date configured to download but not install.  As I
remember, there were no error messages during the install process.

The main issue is user error; I should not have installed before running
db_dumpall and clearing the database area in preparation for the 7.3 upgrade.  I
still think the wierd syntax error thingee indicates that periods seem to no
longer be a good password character -- if the parser is failing the password on
syntax, there appears to be a problem.  Note that it successfully determined
that I had entered an invalid password on the second test; that seems to
indicate correct operation of password symantics. 

After rollback to 7.2 the libraries /usr/lib/lib*psq* still have the same dates
as I displayed above.  That seems to indicate that you are correct about the
libraries too -- they may not have been installed.  However, I have the package
(as the directory listing above shows).

As soon as I get the db_dumpall done, we'll see what happens.  Looks like it
isn't happening tonight -- my daughter is using the system for her computer
science homework.

I maintain several JPEG codecs (8, 12, and 16-bit versions) based on your code
-- that's pretty tight stuff you wrote (very reliable and easy to understand); I
remember your name because once or twice a month I get to stare at your
copyright notices.
Comment 8 Tom Lane 2005-07-28 12:42:27 EDT
I've added a dependency from the base package to rh-postgresql-libs;
this should appear in the next quarterly update.

Note You need to log in before you can comment on or make changes to this bug.