Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVrjD-00C3WX-TV for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 12:01:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sVrjC-000TQ1-1x for pgsql-general@arkaria.postgresql.org; Mon, 22 Jul 2024 12:01:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sVrjB-000TPs-LE for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 12:01:18 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVrj8-000rnq-0p for pgsql-general@lists.postgresql.org; Mon, 22 Jul 2024 12:01:16 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e0874f138aeso1415779276.2 for ; Mon, 22 Jul 2024 05:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1721649672; x=1722254472; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+WJsDEbO1ZcGYXvmqCnOywnujLfMAobfJbayNJTE7uA=; b=GSJFi3VLxT90zCLDWeB4en/xHSCkoIE9GwBvmXYxZf0Oo5CHl3g83fl7DeAobpd9Ac 9bYHMwigYXLItSXlH75D4+nQ1xhSnp5035WUZoph2/DxxqJdVFdYTy1co3RAznSWOR4h u2Y5BnJ+RWQHg7mpAVMYtp5gnM0qLGYEjcTjCNmkblFo1CScadCxlZEJH55+fXawydd2 D6zISZfJgVcJ5Z+FaYbsjE8DQPtaQndHFYYpHHh9dR8STeGiuodDUZbSW81QaL3pZvfR nfWf93ITM2dwQrT/KS/Q3J7ik1dce+4c6Bqt4P1B6QeQEKmuSuzY7roT6LsxJKFvbenb qAlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721649672; x=1722254472; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+WJsDEbO1ZcGYXvmqCnOywnujLfMAobfJbayNJTE7uA=; b=p+FB2ilzVAWP8MzIMpK5QWX1d2CFsJQwBUFsdrrI+RZEohC/W/sv75IoaI6OlJpiNx pxcNArzrMM8d6AXEPOJRdJBmIEBI9pVyXN9zkyxrCzYLWsILOqMenROyDWkFZBmbTSaq gvBulFvPaLZVyxeI49eRMexxipPkrldTmTee3dcm9McI4VkN91QaY95Q6YIkzDnp9kvm FraYOzER/bn5645xLX8Wk83M31NIUyGJ7w0s2jGytL17Za7mTNs/6HL70nJ7svdjIvSp GbXV9kFHp0XjiHyOB8ympCwLzJQZBIzxVfmlCTeoQ6hly9n7QwftcLfAcNRz46PP/TPT p4ng== X-Forwarded-Encrypted: i=1; AJvYcCURPOReu+hw+sFxjIWRcKZLFLRs986QxngJtI8mRGWsbFNSSNLPQBTUThQ3vplOtCtf3Mt+U1ZGs50c1uuKVg0npRkvmmlrujEPmojYcLsnbK6b X-Gm-Message-State: AOJu0YzEQd51dl9rUIXXZ9jkGeSHorY0nWpED09bMpa7wBnrq77CF69w jyobpKSvI5szGYDpoGy3U0Gikg4Q0z1hT1FK5QL2VW1FDsaSm4XAHG7jnpd/OB2yx/EuVR+xrN3 aJf+40nmfkMEuwLZ52JtgGRiaOo7xm6tOCDJx X-Google-Smtp-Source: AGHT+IHRuu+S3TRtE4mUuzlup0yg6cxU5gnB0YupYEhvxHkCab5VJeNcC+nvhMd7vq0rtIAdiz0JH7YNg91IGvslazU= X-Received: by 2002:a05:6902:1509:b0:e03:5ff1:46e2 with SMTP id 3f1490d57ef6-e08701893ffmr7168904276.26.1721649671665; Mon, 22 Jul 2024 05:01:11 -0700 (PDT) MIME-Version: 1.0 References: <80c9b0ea-c874-40ad-a006-fb1eb37464c2@aklaver.com> <44b44ece-dce6-4b4f-b751-8787a5a071e0@aklaver.com> In-Reply-To: From: Sandeep Thakkar Date: Mon, 22 Jul 2024 17:30:54 +0530 Message-ID: Subject: Re: Windows installation problem at post-install step To: Thomas Munro Cc: Adrian Klaver , =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= , pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000001bc530061dd4cd79" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001bc530061dd4cd79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, Jul 22, 2024 at 1:57=E2=80=AFAM Thomas Munro wrote: > On Mon, Jul 22, 2024 at 7:29=E2=80=AFAM Adrian Klaver > wrote: > > On 7/21/24 12:00, Ertan K=C3=BC=C3=A7=C3=BCkoglu wrote: > > > My main purpose was and still is to reach EDB people using the forum > and > > > let them know about the problem. > > > I believe it is something to be fixed for future installations. I wou= ld > > > like to provide additional information if needed. > > > > You could try a back door method and post here: > > > > https://www.postgresql.org/list/pgadmin-support/ > > > > pgAdmin comes from EDB also, maybe someone on that list could pass your > > issue on. > > I guess this is where EDB installer issues should go: > > https://github.com/EnterpriseDB/edb-installers/issues > > It seems like there are about 3 different problems associated with the > new Turkish_T=C3=BCrkiye.1254 locale name: > > 1. EDB's installer apparently has a problem with the encoding of the > name of the locale itself. Looking at your log file with my pager, it > shows: > > The database cluster will be initialized with locale > "Turkish_Trkiye.1254". > > I think that means that it had the name of the locale encoded as > "CP437" at some point (where =C3=BC is 0x81, apparently[1]), but then > somewhere it was reencoded to the sequence 0xc2 0x81 (shown by my > pager as ), which is nonsense. The way to get there would be > to believe falsely that the source encoding was Latin1, I guess. > EDB's windows installer gets the locales on the system using the https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server/scripts/w= indows/getlocales/getlocales.cpp and then substitute some patterns ( https://github.com/EnterpriseDB/edb-installers/blob/REL-16/server/pgserver.= xml.in#L2850) I'm not sure why we do that but that is the old code and probably @Dave Pag= e may know but I'm not sure if that piece of code is responsible for this change in encoding in this case. When I checked the installation log shared by Ertan, I do see that the locale passed to initcluster script is the same as returned by the getlocales executable. Executing C:\Windows\System32\cscript //NoLogo "C:\Program Files\PostgreSQL\16/installer/server/initcluster.vbs" "NT AUTHORITY\NetworkService" "postgres" "****" "C:\Users\User1\AppData\Local\Temp/postgresql_installer_cd79fad8b7" "C:\Program Files\PostgreSQL\16" "C:\DATA_PG16" 5432 "Turkish,T=C3=BCrkiye"= 0 > I'm not even sure what encoding it should be giving to initdb (maybe > the ACP of your system?), and in fact it's a bit undefined for > PostgreSQL at least, but that seems to be double-confused. I suspect > the solution to this might be for EDB's installer to somehow convert > your selected language to the modern short code format, like "tr-TR". > Those are pure ASCII. I don't know where it should get the list from. > > 2. Some existing database clusters which had been installed with the > name "Turkish_Turkey.1254" became unstartable when the OS upgrade > renamed that locale to "Turkish_T=C3=BCrkiye.1254". I'm trying to provid= e > a pathway[2] to fix such systems in core PostgreSQL in the next minor > release. Everyone affected probably already found another way but at > least next time a country is renamed this might help with the next > point too. > > 3. I'd also like to teach initdb to use BCP47 names like "tr-TR" > instead of those names by default (ie if you don't specify a locale > name explicitly), and have proposed that before[3] but it hasn't gone > in due to lack of testing/reviews from Windows users. It seems like > that doesn't matter much in practice to all the people using the > popular EDB installer, since it apparently takes control of picking > the locale and explicitly passes it in (and screws up the encoding as > we have now learned). > > As for your immediate problem, you can also use initdb.exe directly to > set up a cluster, and tell it to use locale tr-TR. I can't recommend > all the switches you'd need to pass it for best compatibility with the > EDB GUI tools though, but maybe the ones from your log. > > [1] https://en.wikipedia.org/wiki/%C3%9C#Computing_codes > [2] > https://www.postgresql.org/message-id/flat/CA%2BhUKGJTOgnTzu4VD6Am0X6g67a= tkQHFVk%2BC-w5wkGrGiao-%3DQ%40mail.gmail.com#556557efd6b83cd7a336b62507efe3= 47 > [3] > https://www.postgresql.org/message-id/flat/CA%2BhUKGJ%3DXThErgAQRoqfCy1bK= PxXVuF0%3D2zDbB%2BSxDs59pv7Fw%40mail.gmail.com > --=20 Sandeep Thakkar --0000000000001bc530061dd4cd79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Jul 22, 2024 at 1:57=E2= =80=AFAM Thomas Munro <thomas.= munro@gmail.com> wrote:
On Mon, Jul 22, 2024 at 7:29=E2=80=AFAM Adrian Klaver <adrian.klaver@= aklaver.com> wrote:
> On 7/21/24 12:00, Ertan K=C3=BC=C3=A7=C3=BCkoglu wrote:
> > My main purpose was and still is to reach EDB people using the fo= rum and
> > let them know about the problem.
> > I believe it is something to be fixed for future installations. I= would
> > like to provide additional information if needed.
>
> You could try a back door method and post here:
>
> https://www.postgresql.org/list/pgadmin-support= /
>
> pgAdmin comes from EDB also, maybe someone on that list could pass you= r
> issue on.

I guess this is where EDB installer issues should go:

https://github.com/EnterpriseDB/edb-installers/= issues

It seems like there are about 3 different problems associated with the
new Turkish_T=C3=BCrkiye.1254 locale name:

1. EDB's installer apparently has a problem with the encoding of the name of the locale itself.=C2=A0 Looking at your log file with my pager, it=
shows:

The database cluster will be initialized with locale
"Turkish_T<U+0081>rkiye.1254".

I think that means that it had the name of the locale encoded as
"CP437" at some point (where =C3=BC is 0x81, apparently[1]), but = then
somewhere it was reencoded to the sequence 0xc2 0x81 (shown by my
pager as <U+0081>), which is nonsense.=C2=A0 The way to get there wou= ld be
to believe falsely that the source encoding was Latin1, I guess.
=C2=A0
EDB's windows installer = gets the locales on the system using the=C2=A0https://github.com/EnterpriseDB/edb-insta= llers/blob/REL-16/server/scripts/windows/getlocales/getlocales.cpp=C2= =A0and then substitute=C2=A0some patterns (https://github.com/EnterpriseDB/edb-installers/blob/REL-1= 6/server/pgserver.xml.in#L2850) I'm not sure why we do that but tha= t is the old code and probably=C2=A0@Dave Page=C2=A0 may know but I'm not sure if = that piece of code is responsible for this change in encoding=C2=A0in this = case.

When I checked the installation log shared by Ertan, I do see = that the locale passed=C2=A0to initcluster script is the same as returned b= y the getlocales executable.

Executing C:\Windows\System32\cscr= ipt //NoLogo "C:\Program Files\PostgreSQL\16/installer/server/initclus= ter.vbs" "NT AUTHORITY\NetworkService" "postgres" = "****" "C:\Users\User1\AppData\Local\Temp/postgresql_install= er_cd79fad8b7" "C:\Program Files\PostgreSQL\16" "C:\DAT= A_PG16" 5432 "Turkish,T=C3=BCrkiye" 0
=C2=A0
=
I'm not even sure what encoding it should be giving to initdb (maybe the ACP of your system?), and in fact it's a bit undefined for
PostgreSQL at least, but that seems to be double-confused.=C2=A0 I suspect<= br> the solution to this might be for=C2=A0 EDB's installer to somehow conv= ert
your selected language to the modern short code format, like "tr-TR&qu= ot;.
Those are pure ASCII.=C2=A0 I don't know where it should get the list f= rom.

2.=C2=A0 Some existing database clusters which had been installed with the<= br> name "Turkish_Turkey.1254" became unstartable when the OS upgrade=
renamed that locale to "Turkish_T=C3=BCrkiye.1254".=C2=A0 I'm= trying to provide
a pathway[2] to fix such systems in core PostgreSQL in the next minor
release.=C2=A0 Everyone affected probably already found another way but at<= br> least next time a country is renamed this might help with the next
point too.

3.=C2=A0 I'd also like to teach initdb to use BCP47 names like "tr= -TR"
instead of those names by default (ie if you don't specify a locale
name explicitly), and have proposed that before[3] but it hasn't gone in due to lack of testing/reviews from Windows users.=C2=A0 It seems like that doesn't matter much in practice to all the people using the
popular EDB installer, since it apparently takes control of picking
the locale and explicitly passes it in (and screws up the encoding as
we have now learned).

As for your immediate problem, you can also use initdb.exe directly to
set up a cluster, and tell it to use locale tr-TR.=C2=A0 I can't recomm= end
all the switches you'd need to pass it for best compatibility with the<= br> EDB GUI tools though, but maybe the ones from your log.

[1] https://en.wikipedia.org/wiki/%C3%9C#Computi= ng_codes
[2] https://www.postgresq= l.org/message-id/flat/CA%2BhUKGJTOgnTzu4VD6Am0X6g67atkQHFVk%2BC-w5wkGrGiao-= %3DQ%40mail.gmail.com#556557efd6b83cd7a336b62507efe347
[3] https://www.postgresql.org/message-id/flat/CA%2BhUKG= J%3DXThErgAQRoqfCy1bKPxXVuF0%3D2zDbB%2BSxDs59pv7Fw%40mail.gmail.com


--
Sandeep Thakkar


--0000000000001bc530061dd4cd79--