From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: James Inform <james.inform@pharmapp.de>,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
        Euler Taveira <euler@eulerto.com>
Subject: Re: BUG #17584: SQL crashes PostgreSQL when using ICU collation
In-reply-to: 
 <CAH2-Wzmqrjqv9pgyzebgnqmcac1Ct+UxG3VQU7kSVUNDf_yF2A@mail.gmail.com>
References: <17584-95c79b4a7d771f44@postgresql.org>
 <f6d74de8-df28-4ef7-8d9e-10f2ab77ea8e@www.fastmail.com>
 <a9851f48-b281-8313-52f4-59ece14adb86@pharmapp.de>
 <465044.1660428315@sss.pgh.pa.us>
 <92087cd5-5410-a4e9-41fe-4ff310439190@pharmapp.de>
 <541938.1660437017@sss.pgh.pa.us>
 <CAH2-Wzk11wvwjhrbje4DDyXydy5pGACb4wNCHCXiuij0Y10h+Q@mail.gmail.com>
 <555147.1660447264@sss.pgh.pa.us>
 <CAH2-Wzn9jjv22x-Vto-5xo_YJNuMWid0xuOGMcN+LYSXRk-PPA@mail.gmail.com>
 <559703.1660450255@sss.pgh.pa.us> <587801.1660457745@sss.pgh.pa.us>
 <CAH2-Wzmqrjqv9pgyzebgnqmcac1Ct+UxG3VQU7kSVUNDf_yF2A@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Sat, 13 Aug 2022 23:31:06 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <651206.1660487132.1@sss.pgh.pa.us>
Date: Sun, 14 Aug 2022 10:25:32 -0400
Message-ID: <651207.1660487132@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/651207.1660487132%40sss.pgh.pa.us>
Precedence: bulk

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