Re: Examining the output of: ldd `which postgres`

From: todd(at)tekinteractive(dot)com (Todd R(dot) Eigenschink)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Examining the output of: ldd `which postgres`
Date: 2003-12-01 23:57:31
Message-ID: m38ylw9jmc.fsf@rtfm.ofc.tekinteractive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sss(dot)pgh(dot)pa(dot)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(at)tekinteractive(dot)com http://www.tekinteractive.com/
System Administrator (260) 459-2521

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sean Chittenden 2003-12-02 00:15:39 Re: [PATCH] Re: [pgsql-advocacy] Why READ ONLY transactions?
Previous Message Bruce Momjian 2003-12-01 23:19:57 Re: [CORE] Commit privs