| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Bryan Green <dbryan(dot)green(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: MSVC: Improve warning options set |
| Date: | 2025-11-10 15:34:10 |
| Message-ID: | 406a52f4-36d2-4e3a-85de-d8d6ab9b7787@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 08.11.25 22:40, Thomas Munro wrote:
> Unfortunately
> it didn't ever seem to become unbuildable, but apparently things break
> in undiagnosed ways at runtime (at a guess it might have some API
> calls that are stubbed out with empty implementations or something
> like that, but there is zero reason to investigate that, it's dead).
> What we should do to make this clearer and avoid spurious problem
> reports is error out unless you're on UCRT, but a patch for that got
> stuck waiting for the Debian images used on CI to be upgraded to
> Debian trixie, because that shipped the necessary newer
> MinGW/headers/etc in its cross-build packages. That has now happened,
> so we should probably go ahead with something like the patch I posted
> here:
>
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BQJv-
> g7C2APVV7O_jEJkxH1AmvgAe8X2vDR8mRdSKn3A%40mail.gmail.com#e6d0c91e2f59e6e39eb61095da4cc598
>
> In theory we could even back-patch that to 18, since we already know
> it won't fully work and we already declared that we don't support it.
> Or we could just let sleeping dogs lie and do that for 19.
When you build master under the msys2 msvcrt environment now, various
regression tests fail, related to floating point differences and locales
not being found. So I think this regulates itself and we don't really
need to do anything further.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-11-10 16:11:00 | Re: Move SLRU_PAGES_PER_SEGMENT to pg_config_manual.h |
| Previous Message | Andrei Lepikhov | 2025-11-10 15:31:07 | Re: Sequence Access Methods, round two |