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-WznXGos_OJ03wJANo_2S_9oVLiJE9E5p7ii6Y_jSpGnkfA@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>
 <651207.1660487132@sss.pgh.pa.us>
 <CAH2-WznXGos_OJ03wJANo_2S_9oVLiJE9E5p7ii6Y_jSpGnkfA@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Sun, 14 Aug 2022 09:17:12 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <775230.1660495370.1@sss.pgh.pa.us>
Date: Sun, 14 Aug 2022 12:42:50 -0400
Message-ID: <775231.1660495370@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/775231.1660495370%40sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> I also suspect that the test case happens to tickle some obscure UCA
> implementation detail in just the right/wrong way, where (for whatever
> reason) it is necessary for the implementation to use a fairly large
> buffer, despite the fact that it knows that its varlena.c caller will
> only require enough conditioned binary key bytes to build an 8 byte
> abbreviated key. It might be very rare and hard to hit (and/or depend
> on the ICU version), which would explain why it took this long to hear
> any complaints. So...I think that it might be quite difficult to test
> this.

I think that on our side, it also requires using incremental sort,
creating yet another obstacle to building a small test case.

> BTW, is the plan to get rid of the questionable coding pattern in both
> varstr_abbrev_convert() and in varstrfastcmp_locale()? I am in favor
> of just using repalloc() across the board.

Yeah, done that way already.

			regards, tom lane