Hi Tom,
Thanks for the quick response. Just a quick followup note though; running=
:
SELECT show=5Ftrgm(maker) =46ROM car=5Fmakers;
behaves properly, but trying to make a similarity comparison triggers the=
segfault (at least in my case). That's why I suspect there may be 2 rela=
ted bugs, one related trigram generation and, maybe, one related to trigr=
am comparison. Hope this info will help you as well.
Regards,
--
Ufuk Kayserilioglu
=46rom:=C2=A0Tom Lane Tom Lane
Reply:=C2=A0Tom Lane tgl=40sss.pgh.pa.us
Date:=C2=A013 January 2014 at 18:09:46
To:=C2=A0ufuk=40paralaus.com ufuk=40paralaus.com
Subject:=C2=A0 Re: =5BBUGS=5D BUG =238821: pg=5Ftrgm segfault with Turkis=
h locale database =20
ufuk=40paralaus.com writes: =20
> Given a database with encoding UT=46-8, locale tr=5FTR.UT=46-8, 'pg=5Ft=
rgm' =20
> extension enabled, and the following setup: =20
> CREATE TABLE car=5Fmakers (maker TEXT); =20
> INSERT INTO car=5Fmakers VALUES ('AUDI'), ('MINI'); =20
> Run any one of the following commands: =20
> - SELECT maker <-> 'MAZDA' =46ROM car=5Fmakers; =20
> - SELECT similarity(maker, 'MAZDA') =46ROM car=5Fmakers; =20
> - SELECT show=5Ftrgm('III'); =20
> As a result, it seems there is a problem with trigrams generation and/o=
r =20
> comparison when the Turkish locale is being used. =20
It looks like generate=5Ftrgm() is not considering the possibility that =20
case-folding will make the string physically longer, so you get a buffer =
=20
overrun when any of these I-containing strings are converted to trigrams.=
=20
Will fix, thanks for the report=21 =20
regards, tom lane =20