Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
От | Thomas Munro |
---|---|
Тема | Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607 |
Дата | |
Msg-id | CA+hUKGLqN3dhHF_Y6rEgKCVxy0f7uCtSEv7okAzz=D96qVj38Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607 (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
RE: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
|
Список | pgsql-bugs |
On Fri, Sep 20, 2024 at 11:37 AM Thomas Munro <thomas.munro@gmail.com> wrote: > If I don't hear any objections to this plan soon, I'm going to commit > this and back-patch it into PostgreSQL 16 and PostgreSQL 17 after the > upcoming code freeze for the PostgreSQL 17 release ends. So it'll > probably be in 16.5 and 17.1. Done, after another round of polishing and testing. The main change since v2 was: I realised that initdb's locale_date_order() also contains a save-and-restore, which should share code at least for consistency (I don't personally know which categories really affect process-wide encoding assumptions, so this might not technically be necessary). I moved the relevant code into new helper functions, which I think came out tidier. The wchar_t-based save-restore in initdb.exe is based on a theoretical observation, as the report was about postgres.exe crashing and that should now be unreachable with these new name checks, but we can see the general phenomenon from a two-line standalone repro[1] and so I suspect there must be environment/input combinations that could crash initdb.exe itself without it. We don't have any concrete reports of that, but I preferred to close the theoretical risk using the recommended technique. Sorry for taking so long to untangle this mess; I assumed for much of the thread that we were talking about the failure of existing clusters to come up (as complained about in numerous other threads), not this new kind of crash, and was trying to fix that before the Locale Builder solution was widely known. Fixing Windows bugs as a non-Windows guy by reading the manual and testing patches on CI can sometimes feel a little like trying to patch a Mars rover... Thanks to David R for help with a crucial observation using a martian debugger. CREATE COLLATION should probably also start using check_locale() eventually, and I may look into harmonising that and figure out how to test it in nearby future work on locales vs threads. [1] https://www.postgresql.org/message-id/CA+hUKG+FxeRLURZ=n8NPyLwgjFds_SqU_cQvE40ks6RQKUGbGg@mail.gmail.com
В списке pgsql-bugs по дате отправления: