Andres Freund writes:
> On 2017-05-31 11:57:16 -0400, Alvaro Herrera wrote:
>> My vote would be to backpatch it all the way.
> +1
Done, buildfarm seems happy.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 2017-05-31 11:57:16 -0400, Alvaro Herrera wrote:
> My vote would be to backpatch it all the way.
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> My vote would be to backpatch it all the way.
That's my thought too. Otherwise it'll be five years before extension
authors can stop worrying about this issue.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Christoph Berg wrote:
> Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us>
> > Next question: should we back-patch this change, or just do it in HEAD?
>
> Debian "needs" it for 9.6, but I've already pushed the s390x patch in
> the original posting, so I could just live with it being just
Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us>
> OK, this looks good to me. Just to make sure everyone's on the
> same page, what I propose to do is simplify all our platform-specific
> Makefiles that use either -fpic or -fPIC to use -fPIC unconditionally.
> This affects the netbsd,
Christoph Berg writes:
> Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us>
>> It'd be interesting if people could gather similar numbers on other
>> platforms of more real-world relevance, such as ppc64. But based on
>> this small sample, I wouldn't object to just going to
Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us>
> It'd be interesting if people could gather similar numbers on other
> platforms of more real-world relevance, such as ppc64. But based on
> this small sample, I wouldn't object to just going to -fPIC across
> the board.
ppc64el, Debian
On Tue, May 30, 2017 at 4:38 PM, Tom Lane wrote:
> It'd be interesting if people could gather similar numbers on other
> platforms of more real-world relevance, such as ppc64. But based on
> this small sample, I wouldn't object to just going to -fPIC across
> the board.
That
I wrote:
> Very possibly true, but I wish we had some hard facts and not just
> guesses.
As a simple but on-point test, I compared sizes of postgres_fdw.so
built with -fpic and -fPIC. I no longer have access to a wide variety
of weird architectures, but on what I do have in my office:
x86_64,
Re: Tom Lane 2017-05-30 <25131.1496163...@sss.pgh.pa.us>
> Christoph Berg writes:
> > My main point here would be that we are already setting this for all
> > extensions for sparc and sparc64, so s390(x) would just follow suit.
>
> For some values of "we", sure ;-).
Afaict for
Christoph Berg writes:
> My main point here would be that we are already setting this for all
> extensions for sparc and sparc64, so s390(x) would just follow suit.
For some values of "we", sure ;-). But I think what is really under
discussion here is whether to change -fpic to
Re: Andres Freund 2017-05-30 <20170530161541.koj5xbvvovrrt...@alap3.anarazel.de>
> I think we can fix this easily enough in Citus, postgis, and whatever.
> But it's not a particularly good user/developer experience, and
> presumably is going to become more and more common. On x86 there
> shouldn't
Andres Freund writes:
> On 2017-05-29 15:45:11 -0400, Tom Lane wrote:
>> 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
On 2017-05-29 15:45:11 -0400, Tom Lane wrote:
> Christoph Berg writes:
> > Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.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
Robert Haas writes:
> On Mon, May 29, 2017 at 3:45 PM, Tom Lane 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,
On Mon, May 29, 2017 at 3:45 PM, Tom Lane wrote:
> 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.
>
Christoph Berg writes:
> Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.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
Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.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:
>
>-fpic
> Generate position-independent code
18 matches
Mail list logo