Re: BUG #8821: pg_trgm segfault with Turkish locale database

Hi Tom,

Thank you so much for the quick turnaround. Indeed, I just built the late=
st version from Git and tested it on one of the original test machines an=
d all cases are working perfectly.

Regards,

--
Ufuk Kayserilioglu

=46rom:=C2=A0Tom Lane Tom Lane
Reply:=C2=A0Tom Lane tgl=40sss.pgh.pa.us
Date:=C2=A013 January 2014 at 21:24:31
To:=C2=A0Ufuk Kayserilioglu ufuk=40paralaus.com
Subject:=C2=A0 Re: =5BBUGS=5D BUG =238821: pg=5Ftrgm segfault with Turkis=
h locale database =20
Ufuk Kayserilioglu <ufuk=40paralaus.com> writes: =20
> Thanks for the quick response. Just a quick followup note though; runni=
ng: =20

> SELECT show=5Ftrgm(maker) =46ROM car=5Fmakers; =20

> behaves properly, but trying to make a similarity comparison triggers t=
he segfault (at least in my case). That's why I suspect there may be 2 re=
lated bugs, one related trigram generation and, maybe, one related to tri=
gram comparison. Hope this info will help you as well. =20

The given cases all work for me with the committed patch to generate=5Ftr=
gm(), =20
http://git.postgresql.org/gitweb/=3Fp=3Dpostgresql.git;a=3Dcommitdiff;h=3D=
c3ccc9ee584b9b015dd9c1931e261e21f3961e5f =20

I'm not going to sit here and claim that there are now zero bugs in =20
pg=5Ftrgm, but I'm not seeing evidence of a second issue. Since the bug i=
s =20
a buffer overrun of just a few bytes, whether it results in a crash in an=
y =20
particular trigram operation is hard to predict; it might just stomp on =20
noncritical memory. =20

regards, tom lane =20