MIME-Version: 1.0
References: <CAH2i4ydECHZPxEBB7gtRG3vROv7a0d3tqAFXzcJWQ9hRsc1znQ@mail.gmail.com>
 <80c9b0ea-c874-40ad-a006-fb1eb37464c2@aklaver.com> <CAH2i4yfkH7YPoLz1aE6MQiBOm8dra5uOTpn51=9ce_Tm6fy3Pw@mail.gmail.com>
 <a9c619c4-f681-4e28-b1d0-cb4845e06fe8@aklaver.com> <CAH2i4ycV8p_uDsdGRcP3bWcU52ogojg9_-mT8uMixSqpNmW7Sg@mail.gmail.com>
 <d55c35b9-a658-4961-849e-871e7dd23fe9@aklaver.com> <CAH2i4yfBEYmOzsvsT=D+ySpLpsEW2O1VfUwx9Ckd69du67YY_w@mail.gmail.com>
 <44b44ece-dce6-4b4f-b751-8787a5a071e0@aklaver.com> <CA+hUKGJA4pGEeZtfUUEuQmNNO7x16wZ+RWOeXP+tq3Hf4iu8oQ@mail.gmail.com>
 <CANFyU95Le+trZbtB1D4Y1FdUu4y_OJLxvJMi1Zb9WOWuf8KpqA@mail.gmail.com>
 <CAH2i4ycX3Q79uv431CxZ9dcyM5jkL=sJ8Z8rbNaNuKSK=Bprfg@mail.gmail.com>
 <CANFyU95q_WDM+utY3Mnrf1pwgASN3ZR1r6Fb+Zs7kXsPEDQQ2A@mail.gmail.com>
 <CANFyU94yoUCYovEZ9By2cpRbHsziRqndfPZ5qiTRD24CM57cEg@mail.gmail.com>
 <CANFyU959RhJvRAY7=8vgN-1f+qKFuK80uFvrR1kMoQMQqzKPQg@mail.gmail.com>
 <CA+hUKGK_LqmzEbR6YjyuQ9eAaecMfogv1e+E-dZVw=qULXtyGQ@mail.gmail.com>
 <CANFyU95vLi3K1FTZO82kYTAGX3B7TPkbWe8LAecaQtndH+EC9Q@mail.gmail.com>
 <CANFyU94tsEhc_i9oap3HHRX2jPwzfXXrn5X=gTLuc9u3w36mWA@mail.gmail.com>
 <CA+hUKGJdyNtKJOA1-7HRbXr4ouaigVXHtoGghay9rWcmYQMhrw@mail.gmail.com> <CANFyU97nU3z2_0QPNopeZB-x9hXRbOU=qAss7726jWaLtgBpGA@mail.gmail.com>
In-Reply-To: <CANFyU97nU3z2_0QPNopeZB-x9hXRbOU=qAss7726jWaLtgBpGA@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Thu, 8 Aug 2024 12:41:29 +1200
Message-ID: <CA+hUKG+FxeRLURZ=n8NPyLwgjFds_SqU_cQvE40ks6RQKUGbGg@mail.gmail.com>
Subject: Re: Windows installation problem at post-install step
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Cc: =?UTF-8?B?RXJ0YW4gS8O8w6fDvGtvZ2x1?= <ertan.kucukoglu@gmail.com>, 
	Adrian Klaver <adrian.klaver@aklaver.com>, pgsql-general@lists.postgresql.org, 
	Manika Singhal <manika.singhal@enterprisedb.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKG%2BFxeRLURZ%3Dn8NPyLwgjFds_SqU_cQvE40ks6RQKUGbGg%40mail.gmail.com>
Precedence: bulk

Thanks.  The log didn't offer any more clues, and my colleague David R
has Windows and knows how to work its debugger so we sat down together
and chased this down (thanks David!).

1.  It is indeed calling abort(), but it's not a PANIC or Assert() in
PostgreSQL, it's an assertion inside Windows' own setlocale():

minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp(245) : Assertion
failed: (pwcs =3D=3D nullptr && sizeInWords =3D=3D 0) || (pwcs !=3D nullptr=
 &&
sizeInWords > 0)

2.  It is indeed confused about the encoding of the string
"Turkish_T=C3=BCrkiye.1254" itself, and works fine if you use "tr-TR".

3.  It doesn't happen on 15, because 16 added a key ingredient:

commit bf03cfd162176d543da79f9398131abc251ddbb9
Author: Peter Eisentraut <peter@eisentraut.org>
Date:   Tue Jan 3 14:21:40 2023 +0100

    Windows support in pg_import_system_collations

That causes it to spin through a bunch of system locales and switch to
them, and the first one is "aa".  After it calls:

    setlocale(2, "aa");

... then the next call to restore the previous locale is something like:

    setlocale(2, "Turkish_T\252rkiye.1254");

(That \252 =3D=3D 0xfc probably depends on your system's default
encoding.)  It doesn't like that name anymore, and aborts.  A minimal
program with just those two lines shows that.

It appears that after switching to "aa", it interprets the string
passed to the next call to setlocale() as some other encoding
(probably UTF-8, I dunno).  I don't know why it doesn't fail and
return NULL, but there is a more general point that it's a bit bonkers
to use non-ASCII byte sequences in the library calls that are used to
control how non-ASCII byte sequences are interpreted.  Maybe it can be
done if you're careful, but in particular a naive save-and-restore
sequence just won't work.

I guess a save-and-restore done with wsetlocale() could fix that.  But
I decline to work on that, we need less Windows kludgery in the tree,
not more.  I think a better answer is "don't do that".

Really, we *have* to chase all these non-BCP-47 locales out of the
installer (I hope you can work on that?), out of PostgreSQL (testers
wanted[1]), and out of the world's existing clusters (maybe with
Dave's pg_upgrade idea, someone would need to write a patch, or maybe
someone could write a stand-alone locale migration program that just
connects to a cluster and (using some authoritative source, that's the
key bit to research) and replaces bad old names with nice new ones).

[1] https://www.postgresql.org/message-id/flat/CA+hUKGJ=3DXThErgAQRoqfCy1bK=
PxXVuF0=3D2zDbB+SxDs59pv7Fw@mail.gmail.com