Skip site navigation (1) Skip section navigation (2)

Re: Clear up strxfrm() in UTF-8 with locale on Windows

From: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
To: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Clear up strxfrm() in UTF-8 with locale on Windows
Date: 2007-04-09 13:21:30
Message-ID: 04d101c77aa9$fc7164e0$c701a8c0@wiseknot.local (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
From: "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>

> The attached patch clears up the usage of strxfrm() on Windows. If the
> server encoding is UTF-8 and the locale is not C, we should use wcsxfrm()
> instead of strxfrm() because UTF-8 locale are not supported on Windows.
> We've already have a special version of strcoll() for Windows, but the
> usage of strxfrm() was still broken.
> When we are caught up in the bug, we see the next error message.
> | ERROR:  invalid memory alloc request size 2147483648
> If the server is wrong configured between the server encoding and the
> locale, strxfrm() could be failed and return values like INT_MAX or
> (size_t)-1. We've passed the result+1 straight to palloc(), so the server
> tried to allocale more than 1GB of memory and gave up.

Ahh..., Certainly, the bug lurked there. probably, your patch will help it.
It was not pursued in Japan for the reasons that the locale had been 
recommended to be used by C up to now. however, It seems to have 
caused the user's confusion. In that sense, I vote.+1

But, I am skeptic the locale setting still functions correctly.

However, I think it is great work.:-)


Hiroshi Saito

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-04-09 13:37:06
Subject: Re: Minor recovery changes
Previous:From: ITAGAKI TakahiroDate: 2007-04-09 11:01:34
Subject: Re: autovacuum multiworkers, patch 5

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group