Re: Windows installation problem at post-install step - Mailing list pgsql-general

On Mon, Jul 22, 2024 at 7:29 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
> On 7/21/24 12:00, Ertan Küçükoglu 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 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 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ürkiye.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_T<U+0081>rkiye.1254".

I think that means that it had the name of the locale encoded as
"CP437" at some point (where ü 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.  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/windows/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 Page  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.

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ürkiye.1254".  I'm trying to provide
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%2BhUKGJTOgnTzu4VD6Am0X6g67atkQHFVk%2BC-w5wkGrGiao-%3DQ%40mail.gmail.com#556557efd6b83cd7a336b62507efe347
[3] https://www.postgresql.org/message-id/flat/CA%2BhUKGJ%3DXThErgAQRoqfCy1bKPxXVuF0%3D2zDbB%2BSxDs59pv7Fw%40mail.gmail.com