On Thu, Jun 15, 2017 at 11:18 PM, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> Hi,
> On Thu, Jun 15, 2017 at 8:36 PM, Peter Eisentraut
> <peter.eisentr...@2ndquadrant.com> wrote:
>> On 6/12/17 00:38, Ashutosh Sharma wrote:
>>> PFA patch that fixes the issue described in above thread. As mentioned
>>> in the above thread, the crash is basically happening in varstr_cmp()
>>> function and  it's  only happening on Windows because in varstr_cmp(),
>>> if the collation provider is ICU, we don't even think of calling ICU
>>> functions to compare the string. Infact, we directly attempt to call
>>> the OS function wsccoll*() which is not expected. Thanks.
>> Maybe just
>> diff --git a/src/backend/utils/adt/varlena.c 
>> b/src/backend/utils/adt/varlena.c
>> index a0dd391f09..2506f4eeb8 100644
>> --- a/src/backend/utils/adt/varlena.c
>> +++ b/src/backend/utils/adt/varlena.c
>> @@ -1433,7 +1433,7 @@ varstr_cmp(char *arg1, int len1, char *arg2, int len2, 
>> Oid collid)
>>  #ifdef WIN32
>>                 /* Win32 does not have UTF-8, so we need to map to UTF-16 */
>> -               if (GetDatabaseEncoding() == PG_UTF8)
>> +               if (GetDatabaseEncoding() == PG_UTF8 && (!mylocale || 
>> mylocale->provider == COLLPROVIDER_LIBC))
>>                 {
>>                         int                     a1len;
>>                         int                     a2len;
> Oh, yes, this looks like the simplest and possibly the ideal way to
> fix the issue. Attached is the patch. Thanks for the inputs.

How will this compare UTF-8 strings in UTF-8 encoding?  It seems to me
that ideally, it should use ucol_strcollUTF8 to compare the same,
however, with patch, it will always ucol_strcoll as we never define
HAVE_UCOL_STRCOLLUTF8 flag on Windows.  We have some multi-byte tests
in src/test/mb directory, see if we can use those to verify these
changes.  I admit that I have not tried to execute those on Windows,
so I have no idea if those even work.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to