Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation
От | Tom Lane |
---|---|
Тема | Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation |
Дата | |
Msg-id | 651207.1660487132@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation
|
Список | pgsql-bugs |
Peter Geoghegan <pg@bowt.ie> writes: > On Sat, Aug 13, 2022 at 11:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> How can we only be reaching this function with sss->collate_c true >> when the prevailing locale isn't that? > We don't trust libc's strxfrm() following the debacle with > locale-aware abbreviated keys back in 2016 (unless the user builds > their own Postgres, and goes out of their way to #define > TRUST_STRXFRM). So the relevant strxfrm() code is arguably dead code. > > ICU is different: our policy with ICU locales has always been to trust > ICU's strxfrm()-like function to agree with ICU's strcoll()-like > function. Ah ... so that explains the OP's observation that this is only seen with ICU locales. When I build with --with-icu and run coverage testing on the core regression tests under LANG=en_US.utf8, I see that most of varstr_abbrev_convert() is reached, but *not* the two buggy buffer-enlargement stanzas. So that explains why we've not seen this in testing. I wonder whether there is a reasonably cheap way to test that. The submitted test case is clearly out of the question to add as a regression test... regards, tom lane
В списке pgsql-bugs по дате отправления: