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

  1. Always use -fPIC, not -fpic, when building shared libraries with gcc.