On Thu, Jul 13, 2017 at 10:30 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> writes:
>> It would be nice to get to the bottom of why we're getting a version
>> mismatch on Windows, since we're clearly not getting one on Linux.
>
> Yeah, that's what's bothering me: as long as that remains unexplained,
> I don't have any confidence that we're fixing the right thing.
Okay, I tried to explore on this a bit and my findings are as follows.
On Linux, the handshake key being generated in plperl code i.e. inside XS_EXTERNAL() in Util.c (generated from Util.xs during build time) and perl code (inside Perl_xs_handshake function) are same which means the following condition inside Perl_xs_handshake() becomes true and therefore, there is no mismatch error.
got = INT2PTR(void*, (UV)(key & HSm_KEY_MATCH));
need = (void *)(HS_KEY(FALSE, FALSE, "", "") & HSm_KEY_MATCH);
if (UNLIKELY(got != need))
goto bad_handshake;
However, on Windows, the handshake key generated in plperl code inside XS_EXTERNAL() and in perl code i.e. inside Perl_xs_handshake() are different thereby resulting in a mismatch error.
Actually the function used for generation of handshake Key i.e HS_KEYp() considers 'sizeof(PerlInterpreter)' to generate the key and somehow the sizeof PerlInterpreter is not uniform in plperl and perl modules incase of Windows but on Linux it remains same in both the modules.
This is how PerlInterpreter is defined in Perl source,
typedef struct interpreter PerlInterpreter;
struct interpreter {
# include "intrpvar.h"
};where intrpvar.h has different variables defined inside it and most of the variables definition are protected with various macros. And there are some macros that are just defined in perl but not in plperl module which means the sizeof(PerlInterpreter) on the two modules are going to be different and thereby resulting in a different key. But, then the point is, why no such difference is observed on Linux. Well, as of now, i haven't found the reason behind it and i am still investigating on it.
--
With Regards,
Ashutosh Sharma
EnterpriseDB:
http://www.enterprisedb.com>
> regards, tom lane