aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-08-31 10:42:05 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2022-08-31 10:42:05 -0400
commita53e0ea782c52da0fd8f9605a63aba276fc17c13 (patch)
tree98ff76b20b1f3fa59788d393da75195b1ed73c09 /src/backend/access/gist
parent68bfe36c5173e8e121f0a9eaf0310c1a7ba6d555 (diff)
downloadpostgresql-a53e0ea782c52da0fd8f9605a63aba276fc17c13.tar.gz
postgresql-a53e0ea782c52da0fd8f9605a63aba276fc17c13.zip
In the Snowball dictionary, don't try to stem excessively-long words.
If the input word exceeds 1000 bytes, don't pass it to the stemmer; just return it as-is after case folding. Such an input is surely not a word in any human language, so whatever the stemmer might do to it would be pretty dubious in the first place. Adding this restriction protects us against a known recursion-to-stack-overflow problem in the Turkish stemmer, and it seems like good insurance against any other safety or performance issues that may exist in the Snowball stemmers. (I note, for example, that they contain no CHECK_FOR_INTERRUPTS calls, so we really don't want them running for a long time.) The threshold of 1000 bytes is arbitrary. An alternative definition could have been to treat such words as stopwords, but that seems like a bigger break from the old behavior. Per report from Egor Chindyaskin and Alexander Lakhin. Thanks to Olly Betts for the recommendation to fix it this way. Discussion: https://postgr.es/m/1661334672.728714027@f473.i.mail.ru
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions