Re: Examining the output of: ldd `which postgres` - Mailing list pgsql-hackers

From todd@tekinteractive.com (Todd R. Eigenschink)
Subject Re: Examining the output of: ldd `which postgres`
Date
Msg-id m38ylw9jmc.fsf@rtfm.ofc.tekinteractive.com
Whole thread Raw
In response to Examining the output of: ldd `which postgres`  (Sean Chittenden <sean@chittenden.org>)
List pgsql-hackers
[Up front: yes, I'm following up to a post that's nearly three months
old.  I can't find any more recent discussion of this issue.]


tgl@sss.pgh.pa.us (Tom Lane) writes:
> (Of course, if you can show that there's a significant penalty in
> backend launch time from having useless shlibs linked in, I'd get
> more excited about it...)


How about failure to start at all, when an otherwise-unnecessary
shared library is removed from the system?

For example, all of our boxes have readline as a non-shared
library...except for one.  At some point, a newer, non-shared version
was installed on this particular machine, and the shared lib was
removed.  The next time the machine was rebooted, some months later,
Postgres wouldn't start due to the missing dependency.

I've been re-linking the backend by hand without readline and ncurses
after compiling a new version, and just not worrying about the rest of
the tools.  Today after finding this thread, I decided to see what
could be removed.  I wrote a short combo of shell and perl to
brute-force relink everything in the pgsql/bin directory, to see what
could be removed.  Boy, was I surprised:


Relinking ./src/bin/scripts/clusterdb
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/createdb
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/createlang
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/createuser
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/dropdb
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/droplang
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/dropuser
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/interfaces/ecpg/preproc/ecpg
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/pg_controldata/pg_controldata
Successfully removed: -lpq -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/pg_dump/pg_dump
Successfully removed: -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/pg_dump/pg_dumpall
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/pg_encoding/pg_encoding
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lpgport

Relinking ./src/bin/pg_id/pg_id
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm -lpgport

Relinking ./src/bin/pg_resetxlog/pg_resetxlog
Successfully removed: -lpq -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/pg_dump/pg_restore
Successfully removed: -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/backend/postgres
Successfully removed: -lz -lreadline -lncurses -lresolv -lnsl

Relinking ./src/bin/psql/psql
Successfully removed: -lz -lcrypt -lresolv -lnsl -ldl -lm

Relinking ./src/bin/scripts/vacuumdb
Successfully removed: -lz -lreadline -lncurses -lcrypt -lresolv -lnsl -ldl -lm


(Code on request to anyone who wants it, but warning: it's stupid.)


It might just be me, but it seems like psql starts up faster without
the extraneous libs.  It's always fast, but seems instantaneous now.

I don't know...it seems crazy, but maybe something like my tool could
be included, if you want to relink your setup down to the minimum
necessary libraries?


Todd
-- 
Todd R. Eigenschink             TEK Interactive Group, Inc.
todd@tekinteractive.com         http://www.tekinteractive.com/
System Administrator            (260) 459-2521


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Proposed Query Planner TODO items
Next
From: ramirez@idconcepts.org (Edwin S. Ramirez)
Date:
Subject: Postgres 7.3.5 and count('x')