Re: Fixing MSVC's inability to detect elog(ERROR) does not return - Mailing list pgsql-hackers

From David Rowley
Subject Re: Fixing MSVC's inability to detect elog(ERROR) does not return
Date
Msg-id CAApHDvpZyaTcyjrQ0cYxusJe6M=6QrmfZHue=Q1=7+ZpWymHHA@mail.gmail.com
Whole thread Raw
In response to Re: Fixing MSVC's inability to detect elog(ERROR) does not return  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Fixing MSVC's inability to detect elog(ERROR) does not return
List pgsql-hackers
On Thu, 24 Jul 2025 at 23:03, Peter Eisentraut <peter@eisentraut.org> wrote:
> Please review my patch at
>
> https://www.postgresql.org/message-id/ccb273c9-7544-4748-8638-30feba212e6e@eisentraut.org
> https://commitfest.postgresql.org/patch/5934/

Now that we're building with C11, here's a rebased patch with the new
pg_builtin_constant() macro.

I did some study into the code generation with the patched version. I
see that errstart_cold() is being used correctly when the elevel is >=
ERROR. Unfortunately, MSVC does not seem to have anything like
__attribute__((cold)), so that does nothing different than what
errstart() does.

I also looked at the size of postgres.exe to see if the code
generation had improved due to ereport_domain's __assume(0) being
correctly picked up now. I was surprised to see that the binary had
increased in size by about 13K:

master: 10147840 bytes.
patched: 10161152 bytes.

Most of this extra seems to come from the errstart_cold function, as
if I adjust ereport_domain with:

-                       errstart_cold(elevel, domain) : \
+                       errstart(elevel, domain) : \

The size is 10149888 bytes, or 2k more than master.

The reason I looked into this is because I wanted to check MSVC was
correctly eliminating the errstart_code / errstart ternary condition.
It does. I'm not sure where the extra 2k comes from, however.

I'm unable to detect any performance differences running pgbench -M
prepared -T 60 -S or with pgbench -M simple -T 60 -S.

David

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: SQL:2023 JSON simplified accessor support
Next
From: Chao Li
Date:
Subject: Re: SQL:2023 JSON simplified accessor support