Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Christoph Berg <myon@debian.org>, Andres Freund <andres@anarazel.de>,
Jason Petersen <jason@citusdata.com>, pgsql-pkg-debian@postgresql.org,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-05-30T14:12:46Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, May 29, 2017 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I wonder what the overhead is of using -fPIC when -fpic would be >> sufficient. > Do we have an idea how to measure the increased overhead? Just from > reading the description, I'm guessing that the increased cost would > happen when the extension calls back into core, but maybe that doesn't > happen often enough to worry about? My gut feeling is that it'd be a pretty distributed cost, because every internal cross-reference in the .so (for instance, loading the address of a string literal) would involve a bit more overhead to support a wider offset field. An easy thing to look at would be how much the code expands by. That might or might not be a good proxy for the runtime slowdown percentage, but it seems like it ought to serve as a zero-order approximation. regards, tom lane
Commits
-
Always use -fPIC, not -fpic, when building shared libraries with gcc.
- cee7238de58f 9.3.18 landed
- a378b9bc287d 9.2.22 landed
- 8d9b4fe01b5e 9.6.4 landed
- 894ce0e97ab1 9.4.13 landed
- 68938ab8ea0e 9.5.8 landed
- e9a3c047a5fc 10.0 landed