| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Reduce function call costs on ELF platforms |
| Date: | 2021-11-24 18:55:59 |
| Message-ID: | 20211124185559.mwyeeugivhu5fjbp@alap3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-11-23 17:28:08 +0100, Peter Eisentraut wrote:
> On 22.11.21 23:32, Tom Lane wrote:
> > > The easier approach for this class of issues is to use the linker option
> > > -Bsymbolic.
> > I don't recall details, but we've previously rejected the idea of
> > trying to use -Bsymbolic widely; apparently it has undesirable
> > side-effects on some platforms. See commit message for e3d77ea6b
> > (hopefully there's some detail in the email thread [1]). It sounds
> > like you're not actually proposing that, but I thought it would be
> > a good idea to note the hazard here.
>
> Also, IIRC, -Bsymbolic was once frowned upon by packaging policies, since it
> prevents use of LD_PRELOAD. I'm not sure what the current thinking there
> is, however.
It doesn't break some (most?) of the uses of LD_PRELOAD. In particular, it
doesn't break things like replacing the malloc implementation. When do you
have a symbol that you want to override *inside* your library (executables
already bind to their own symbols at compile time)? I've seen that for
replacing buggy functions in closed source things, but that's about it?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-11-24 18:58:00 | Re: pgsql: xlog.c: Remove global variables ReadRecPtr and EndRecPtr. |
| Previous Message | Alvaro Herrera | 2021-11-24 18:54:37 | Re: Should rename "startup process" to something else? |