From: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: C11 / VS 2019 |
Date: | 2025-07-07 13:19:39 |
Message-ID: | CAN55FZ03ZXUFsxiyR0hzFsrYG-jbQzt8=uoC8b16THu3kU92fg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Mon, 7 Jul 2025 at 13:51, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 06.07.25 00:27, Tom Lane wrote:
> > Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> >> On 04.06.25 08:15, Peter Eisentraut wrote:
> >>> For an explanation, the background is that MSVC has a "traditional"
> >>> preprocessor and a new "conforming" one. The latter is available
> >>> starting in VS 2019, but it's not the default. We have some code,
> >>> especially around __VA_ARGS__ that specifically caters to this
> >>> traditional preprocessor.
> >
> >> I have committed this.
> >
> > Buildfarm member drongo has been failing in initdb since 1 July:
> >
> > selecting default time zone ... UTC
> > creating configuration files ... ok
> > running bootstrap script ...
> > ----------------------------------- stderr -----------------------------------
> > TRAP: failed Assert("SysCache[cacheId]->cc_nkeys == 2"), File: "../pgsql/src/backend/utils/cache/syscache.c", Line: 237, PID: 2684
> > child process was terminated by exception 0xC0000409
> >
> > While there are 19 new commits in the first run that shows this
> > failure [1], the only one that looks plausibly related is
> >
> > 8fd9bb1d965 Tue Jul 1 07:41:40 2025 UTC Enable MSVC conforming preprocessor
> >
> > because that changed our implementation of VA_ARGS_NARGS(), which is
> > what's used to compute the cc_nkeys fields for syscaches.
> >
> > My conclusion is that Microsoft's "standards conforming" preprocessor
> > is not so standards conforming as all that.
>
> Hmm. We have the (allegedly) same VS version in Cirrus CI, and it's
> never shown a problem like this.
CI uses the latest VS 2019 (v16.11.48), it looks like buildfarm member
drongo uses VS 2019 v16.3.1. I created a custom Windows VM with the
same VS 2019 version (v16.3.1) at the drongo and CI failed with the
same error [1].
[1] https://cirrus-ci.com/task/6271845944524800
--
Regards,
Nazir Bilal Yavuz
Microsoft
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2025-07-07 13:30:08 | Re: Using failover slots for PG-non_PG logical replication |
Previous Message | Dmitry Dolgov | 2025-07-07 13:06:41 | Re: Changing shared_buffers without restart |