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: