Re: [PATCH] relocation truncated to fit: citus build failure on s390x

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jason Petersen <jason(at)citusdata(dot)com>, pgsql-pkg-debian(at)postgresql(dot)org, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] relocation truncated to fit: citus build failure on s390x
Date: 2017-05-29 19:45:11
Message-ID: 27883.1496087111@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-pkg-debian

Christoph Berg <myon(at)debian(dot)org> writes:
> Re: To Andres Freund 2016-04-28 <20160428080824(dot)GA22412(at)msg(dot)df7cb(dot)de>
>>> I'm not clear why citus triggers this, when other extensions don't?

>> Maybe it's simply because citus.so is bigger than all the other
>> extension .so files:

I wonder what the overhead is of using -fPIC when -fpic would be
sufficient. Whatever it is, the proposed patch imposes it on every
shlib or extension, to accommodate one single extension that isn't
even one we ship.

Maybe this is small enough to not be something we need to worry about,
but I'm wondering if we should ask citus and other large .so's to set
some additional make flag that would cue usage of -fPIC over -fpic.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-05-29 19:55:08 Re: Use of non-restart-safe storage by temp_tablespaces
Previous Message Andres Freund 2017-05-29 19:44:52 Re: logical replication busy-waiting on a lock

Browse pgsql-pkg-debian by date

  From Date Subject
Next Message Robert Haas 2017-05-30 14:02:56 Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Previous Message Christoph Berg 2017-05-29 15:58:50 Re: [PATCH] relocation truncated to fit: citus build failure on s390x