Re: MSVC: Improve warning options set

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.

In response to

Browse pgsql-hackers by date

  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