Hi Thomas and team,
Just would like to follow up with you about this bug. Is the bug fix available? We noticed that there is a new build
17.0-1.However the issue repro on that build too.
Thanks!
Haifang
-----Original Message-----
From: Thomas Munro <thomas.munro@gmail.com>
Sent: Friday, October 4, 2024 6:17 PM
To: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Cc: Haifang Wang (Centific Technologies Inc) <v-haiwang@microsoft.com>; Tom Lane <tgl@sss.pgh.pa.us>; Andrew Dunstan
<andrew@dunslane.net>;Rahul Pandey <pandeyrah@microsoft.com>; Vishwa Deepak <Vishwa.Deepak@microsoft.com>; Shawn Steele
<Shawn.Steele@microsoft.com>;Amy Wishnousky <amyw@microsoft.com>; pgsql-bugs@lists.postgresql.org; Shweta Gulati
<gulatishweta@microsoft.com>;Ashish Nawal <nawalashish@microsoft.com>
Subject: Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
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
personallyknow 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.execrashing and that should now be unreachable with these new name checks, but we can see the general
phenomenonfrom a two-line standalone repro[1] and so I suspect there must be environment/input combinations that could
crashinitdb.exe itself without it. We don't have any concrete reports of that, but I preferred to close the
theoreticalrisk 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
ofexisting clusters to come up (as complained about in numerous other threads), not this new kind of crash, and was
tryingto fix that before the Locale Builder solution was widely known. Fixing Windows bugs as a non-Windows guy by
readingthe manual and testing patches on CI can sometimes feel a little like trying to patch a Mars rover... Thanks to
DavidR 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
figureout 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
