Re: Getting server crash on Windows when using ICU collation

Hi,

On Tue, Jun 20, 2017 at 2:36 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 6/19/17 00:42, Ashutosh Sharma wrote:
>>> If we don't find unconv, isn't it better to fall back to non-UTF8
>>> version rather than saying command not found?
>> Well, if any of the ICU package is installed on our system then we
>> will certainly find uconv command. The only case where we can see such
>> error is when user doesn't have any of the ICU packages installed on
>> their system and are somehow trying to perform icu enabled build and
>> in such case the build configuration has to fail which i think is the
>> expected behaviour. Anyways, it is not uconv that decides whether we
>> should fallback to non-UTF8 or not. It's the ICU version that decides
>> whether to stick to UTF8 or fallback to nonUTF8 version. Thanks.
>
> How do we know we're running the uconv command from the installation
> that we will compile against?

Okay, I think, you are talking about the case where we may have
multiple ICU versions installed on our system and there might be a
possibility that the uconv command may get executed from the ICU
version that we are not trying to link with postgres. This can only
happen when user has set the path for icu binaries in the system PATH
variable incorrectly. For e.g., if i have installed ICU versions 49
and 53 on my system and the library and include path i am trying to
add is from ICU version 53 whereas the system PATH points to dll's
from ICU 49 then that will be considered as a incorrect build setup.
In this case, even if i am trying to use ICU 53 libraries but as
dll's i am using is from ICU 49 (as my system PATH is pointing to ICU
49 bin path) the uconv -V output would be '49.1' instead of '53.1'. In
such case, the postgres installation would fail because during
installation it would search for libicu53.dll not libicu49.dll.
Therefore, even if we are running wrong uconv command, we would not at
all succeed with the installation process. Hence, i think, we
shouldn't be worrying about any such things. Please let me know if i
could answer your question or not. Thanks.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com