Message-ID: <01fc00fd66f641b9693d4f9f1af0ccf44cbdfbdf.camel@j-davis.com>
Subject: Re: Remaining dependency on setlocale()
From: Jeff Davis <pgsql@j-davis.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Thomas Munro
	 <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-hackers@postgresql.org
Date: Tue, 16 Dec 2025 12:04:54 -0800
In-Reply-To: <651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com>
References: <4c5da86af36a0d5e430eee3f60ce5e06f1b5cd34.camel@j-davis.com>
	 <a8666c391dfcabe79868d95f7160eac533ace718.camel@j-davis.com>
	 <6956823dd669abc64183fc91e64dc2e56e31f3ea.camel@j-davis.com>
	 <ed394f839d813762ddcd65cfcab0e062f8b5e0b1.camel@j-davis.com>
	 <CA+hUKGLYcbnHBXhHk_OFwZ03LE+D=cAirm7TVN8fMhT9rgcTbA@mail.gmail.com>
	 <f040113cf384ada69558ec004a04a3ddb3e40a26.camel@j-davis.com>
	 <CA+hUKGJxSDFcTZSGi++PTC=jM49q1oK=v7Lcdf96VQXXvLhoow@mail.gmail.com>
	 <cdd20efc0f5418c597791a1e3a5abb68fa3ce35b.camel@j-davis.com>
	 <d9657a6e51aa20702447bb2386b32fea6218670f.camel@j-davis.com>
	 <b1ea6756-279a-4924-9146-e125af2057b2@eisentraut.org>
	 <8186b28a1a39e61a0d833a4c25a8909ebbbabd48.camel@j-davis.com>
	 <450ceb6260cad30d7afdf155d991a9caafee7c0d.camel@j-davis.com>
	 <DDD50039-02B4-4033-8D22-B086BC448E1C@gmail.com>
	 <78edc741a168c54d57cc898a5877b6443527a2c8.camel@j-davis.com>
	 <83F6E6A9-FF29-41C9-9E15-EA5360E912D0@gmail.com>
	 <5f65b85740197ba6249ea507cddf609f84a6188b.camel@j-davis.com>
	 <38f3f4a6-e95e-47a7-914f-110dd6191301@eisentraut.org>
	 <0e186a9a92634f0c5675a618ff5685d00cd8f836.camel@j-davis.com>
	 <0E8DD47F-710D-45E1-B87F-2336042A377E@gmail.com>
	 <5f70ee8a3f73df753285f8928c01dd32f14d7fcb.camel@j-davis.com>
	 <651F79AB-8E21-4CDD-9A5A-221AC271265E@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1.1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/01fc00fd66f641b9693d4f9f1af0ccf44cbdfbdf.camel%40j-davis.com>
Precedence: bulk

On Tue, 2025-12-16 at 09:32 +0800, Chao Li wrote:
> I have re-reviewed 0003-0005 last week, they all look good to me.
>=20
> I have no comment on backport 0003.

Committed 0003 and backported to 14.

Committing 0004 also. For the archives, the bug in that case is:

  -- generate some randomly-cased non-ASCII data
  CREATE DATABASE i TEMPLATE template0 LOCALE 'C'
    LOCALE_PROVIDER 'icu' ICU_LOCALE 'en';
  \c i
  CREATE EXTENSION ltree;
  CREATE TABLE test(path ltree);
  CREATE FUNCTION gen() RETURNS TEXT LANGUAGE plpgsql AS $$
    declare
      s TEXT;
    begin
      s :=3D '';
      for i in 1..5 loop
        s :=3D s || case when random() > 0.5 then lower(U&'\00C1') else
U&'\00C1' end;
        s :=3D s || case when random() > 0.5 then lower(U&'\00C9') else
U&'\00C9' end;
        s :=3D s || case when random() > 0.5 then lower(U&'\00CD') else
U&'\00CD' end;
        s :=3D s || case when random() > 0.5 then lower(U&'\00D3') else
U&'\00D3' end;
        s :=3D s || case when random() > 0.5 then lower(U&'\00DA') else
U&'\00DA' end;
      end loop;
      return s;
    end;
  $$;
  INSERT INTO test select ('a.'||gen()||'.z')::ltree
    FROM generate_series(1,10000);
  CREATE INDEX test_idx ON test USING gist (path);
  -- returns 10000
  SET enable_seqscan =3D true;
  SET enable_indexscan =3D false;
  SET enable_bitmapscan =3D false;
  SELECT COUNT(*) FROM test
    WHERE path ~ U&'a.=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=
=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=
=C3=A9=C3=AD=C3=B3=C3=BA@.z'::lquery;
  -- returns fewer tuples when using index scan
  SET enable_seqscan =3D false;
  SET enable_indexscan =3D true;
  SET enable_bitmapscan =3D true;
  SELECT COUNT(*) FROM test
    WHERE path ~ U&'a.=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=
=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA=C3=A1=
=C3=A9=C3=AD=C3=B3=C3=BA@.z'::lquery;

Probably a smaller case would do, but I think it requires page splits
to hit the bug. 0004 fixes the bug.

> The old code didn=E2=80=99t create a locale object and store in result, t=
hus
> it didn=E2=80=99t have a logic to free the created locale. This patch now
> dose that, but I don=E2=80=99t see where the created locale object is fre=
e-
> ed. I suppose newlocale() will allocate memory from the OS, so I
> guess the memory should be free-ed somewhere.

The pg_locale_t objects are cached for the life of the backend, and
never freed. We may want to change that eventually, but in practice
it's not much of a problem.

Regards,
	Jeff Davis