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 1sVgRi-00B6ev-Ee for pgsql-general@arkaria.postgresql.org; Sun, 21 Jul 2024 23:58:30 +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 1sVgRf-00CwKS-Et for pgsql-general@arkaria.postgresql.org; Sun, 21 Jul 2024 23:58:27 +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 1sVgRf-00CwKK-2b for pgsql-general@lists.postgresql.org; Sun, 21 Jul 2024 23:58:27 +0000 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVgRc-000mNR-Ln for pgsql-general@lists.postgresql.org; Sun, 21 Jul 2024 23:58:26 +0000 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-4ef12e5658bso1153437e0c.2 for ; Sun, 21 Jul 2024 16:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721606302; x=1722211102; 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=zB4+SYpEdtiOYxujebrovAF/TB5QRkUU5H7cIUS1+B4=; b=ReXigOxVN27KH1UarjEcByKEP9xqhKLXcA++wl2+im9ClwT5y6KQi5yaTftg9+uU1M 2DcmL7L6/KYk6OhBKCjXvozJBAnPtLNkajbqFCIkI5e3YZ7JeL1PATc4mgd+ixJTeNWT 0YiRSu5B5sJRrddWE5qIhuLWjzkH6fXbl2miUnY2gvcI2LJUe9zWU2z7VedDi+CJyDV0 sqOEtl13ry2lCiBelpad3w9pjzgN1STTiJxWuj6nlQitXylwQUI5b3AwO0l4FP/KduW0 S4I0b2bQqLsDkY4aSDFzEyCSsvyN9k5vG/oQG7w56hT+CFh+iLmdW2fw00uqMmYYS/4+ Yeqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721606302; x=1722211102; 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=zB4+SYpEdtiOYxujebrovAF/TB5QRkUU5H7cIUS1+B4=; b=ODssmq5qg9j3M4AotMHTYUrmN1N5chEJOvc88cUTutb6H8k47TjeCmxUT5IHTP97l1 ui1I73IdF4RnJgi74VxqSwzlqDc/VM8zVlBtN35tXPjogJ2pmQRWS4ix6P0S7Q+YITYx 3FOSQCHGT/NQvXIRxsjiyPeMZwmxyaP896iEBYS2N87bQXK98Y4CJa3wLVT5oxlMW2vi yoYe3O29+iCZ1f90xHGSItvsg5grpPPbxvRGQBe7rrlDZkbsy9miBrvBHlviwn/nqEXU cQ6ixn029o0zmcjHzIkJc1jQIumRCvZeRfpVEEQYqIY3A2WcjOJlzjECp4yWcDjalqxQ iEFA== X-Forwarded-Encrypted: i=1; AJvYcCVTWiCM1OWi02VzOhdnMI2JRpgcAjXbQDjkkle5AvNeAzPc4SIs9q6+M9lOOdqPZkyIwMa0ExBgkcK9H6kDqTZAoWiPblANVJdeWHoBj1ydUR46 X-Gm-Message-State: AOJu0YxGa/idmcVXlO6S6My40ybfTDgjn+m0Hq/U8Gk0zRnbiIshH/iu kxjpswjH9BHSrvb50JNHtvZtIUcXRbWuMJ5PDJc7UTQ4oCzW1w3O5ag9huRJj0Rbm71OkgX465u a/NANpl9Q0JQu1sRiMBrRkvejBp4= X-Google-Smtp-Source: AGHT+IEBO+8Mv1qyofNGo/p352XFyndrkSQ+FYYX/fYD7E+SSgfN7E/QWJPoUbnayBTOK+h0hTJYAyEfyFt940rPE4I= X-Received: by 2002:a05:6102:2911:b0:48f:e658:66ab with SMTP id ada2fe7eead31-49283f8d186mr3124087137.27.1721606301919; Sun, 21 Jul 2024 16:58:21 -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: =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= Date: Mon, 22 Jul 2024 02:58:11 +0300 Message-ID: Subject: Re: Windows installation problem at post-install step To: Thomas Munro Cc: Adrian Klaver , pgsql-general@lists.postgresql.org, Sandeep Thakkar Content-Type: multipart/alternative; boundary="00000000000011b2b1061dcab44c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000011b2b1061dcab44c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thomas Munro , 21 Tem 2024 Paz, 23:27 tarihinde =C5=9Funu yazd=C4=B1: > I guess this is where EDB installer issues should go: > > https://github.com/EnterpriseDB/edb-installers/issues Thanks. I just added a new issue there. 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. > I was also hit by that OS update. There is a Microsoft tool for creating a locale installer https://www.microsoft.com/en-us/download/details.aspx?id=3D41158 Using that tool and adding a second locale Turkish_Turkey.1254 (name before Microsoft update) in the OS can fix your broken PostgreSQL. I believe most people simply choose this path. There are also several blogs/articles written in Turkish about the problem. 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). > If I am not mistaken BCP47 names are already used in Linux systems. Using them would make PostgreSQL use the same locale names across Linux and Windows systems. I can help with the testing part. Let me know the details, please. Thanks & Regards, Ertan --00000000000011b2b1061dcab44c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thomas Munro <thomas.munro@gmail.com>, 21 Tem 2024 Paz, 23:27 ta= rihinde =C5=9Funu yazd=C4=B1:
I guess this is where EDB installe= r issues should go:

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

Thanks. I just added a new issue= there.

2.=C2=A0 Some existing database clusters which had been installed with t= he
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.

I was also hit by that OS up= date.
There is a Microsoft tool for creating a locale installer= =C2=A0
Using that tool and adding a second locale Tur= kish_Turkey.1254 (name before Microsoft update) in the OS can fix your brok= en PostgreSQL.
I believe most people simply choose this path.
There are also several blogs/articles written in Turkish about the p= roblem.

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).

If I am not mista= ken BCP47 names are already used in Linux systems.
Using them wou= ld make PostgreSQL use the same locale names across Linux and Windows syste= ms.
I can help with the testing part. Let me know the details, pl= ease.

Thanks & Regards,
Ertan
<= /div>
--00000000000011b2b1061dcab44c--