Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x |
Дата | |
Msg-id | 20170530161541.koj5xbvvovrrtxtd@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x |
Список | pgsql-hackers |
On 2017-05-29 15:45:11 -0400, Tom Lane wrote: > Christoph Berg <myon@debian.org> writes: > > Re: To Andres Freund 2016-04-28 <20160428080824.GA22412@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 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. 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 be a difference in efficiency between the two, but some others will see some. Given that most distributions switched to building the main executables with -fPIE anyway, to allow for ASLR, it seems unlikely that the intra extension overhead is going to be very meaningful in comparison. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: