Re: [HACKERS] pl/perl extension fails on Windows

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: [HACKERS] pl/perl extension fails on Windows
Дата
Msg-id CAA4eK1JGuf+UZcAB33TwEE-7aZZpNx-PPc=wjjgZVrr8ivFa+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pl/perl extension fails on Windows  (Noah Misch <noah@leadboat.com>)
Ответы Re: [HACKERS] pl/perl extension fails on Windows  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: [HACKERS] pl/perl extension fails on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jul 24, 2017 at 11:58 AM, Noah Misch <noah@leadboat.com> wrote:
> On Wed, Jul 19, 2017 at 05:01:31PM -0400, Tom Lane wrote:
>> Ashutosh Sharma <ashu.coek88@gmail.com> writes:
>> > Here are the list of macros and variables from 'intrpvar.h' file that
>> > are just defined in perl module but not in plperl on Windows,
>>
>> > #ifdef PERL_USES_PL_PIDSTATUS
>> > PERLVAR(I, pidstatus,   HV *)       /* pid-to-status mappings for waitpid */
>> > #endif
>>
>> > #ifdef PERL_SAWAMPERSAND
>> > PERLVAR(I, sawampersand, U8)        /* must save all match strings */
>> > #endif
>>
>> I am really suspicious that this means your libperl was built in an unsafe
>> fashion, that is, by injecting configuration choices as random -D switches
>> in the build process rather than making sure the choices were recorded in
>> perl's config.h.  As an example, looking at the perl 5.24.1 headers on
>> a Fedora box, it looks to me like PERL_SAWAMPERSAND could only get defined
>> if PERL_COPY_ON_WRITE were not defined, and the only way that that can
>> happen is if PERL_NO_COW is defined, and there are no references to the
>> latter anyplace except in this particular #if defined test in perl.h.
>>
>> Where did your perl installation come from, anyway?  Are you sure the .h
>> files match up with the executables?
>
> I see corresponding symptoms with the following Perl distributions:
>
> strawberry-perl-5.26.0.1-64bit.msi:
>   src/pl/plperl/Util.c: loadable library and perl binaries are mismatched (got handshake key 0000000011800080, needed
0000000011c00080)
> ActivePerl-5.24.1.2402-MSWin32-x64-401627.exe:
>   src/pl/plperl/Util.c: loadable library and perl binaries are mismatched (got handshake key 0000000011500080, needed
0000000011900080)
>
> So, this affects each of the two prominent families of Perl Windows binaries.
>

I think the real question is where do we go from here.  Ashutosh has
proposed a patch up-thread based on a suggestion from Andrew, but it
is not clear if we want to go there as that seems to be bypassing
handshake mechanism.  The other tests and analysis seem to indicate
that the new version Perl binaries on Windows are getting built with
flags that are incompatible with what we use for plperl and it is not
clear why perl is using those flags.  Do you think we can do something
at our end to make it work or someone should check with Perl community
about it?

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade
Следующее
От: Alexey Bashtanov
Дата:
Сообщение: [HACKERS] estimation for join results cardinality is sometimes more than theproduct of the downstream nodes'