From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <stark(at)mit(dot)edu> |
Subject: | Re: Current int & float overflow checking is slow. |
Date: | 2017-10-31 05:50:06 |
Message-ID: | CA+TgmobAtW6CwkOXzrhWiZRXSOEd+8O88PWNA+y-U8WNX9iWYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 30, 2017 at 11:24 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> > Perhaps it should rather be pg_add_s32_overflow, or a similar
>> > naming scheme?
>>
>> Not sure what the s is supposed to be? Signed?
>
> Yes, signed. So we could add a u32 or something complementing the
> functions already in the patch. Even though overflow checks are a heck
> of a lot easier to write for unsigned ints, the intrinsics are still
> faster. I don't have any sort of strong feelings on the naming.
Right, I guess including the s is probably a good idea then.
>> I suggest that if we think we don't need -fwrapv any more, we ought to
>> remove it. Otherwise, we won't find out if we're wrong.
>
> I agree that we should do so at some point not too far away in the
> future. Not the least because we don't specify this kind of C dialect in
> a lot of other compilers. Additionally the flag causes some slowdown
> (because e.g. for loop variables are optimized less). But I'm fairly
> certain it needs a bit more care that I've invested as of now - should
> probably at least compile with -Wstrict-overflow=some-higher-level, and
> with ubsan. I'm fairly certain there's more bogus overflow checks
> around...
Makes sense.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2017-10-31 06:59:10 | Re: [bug fix] postgres.exe crashes with access violation on Windows while starting up |
Previous Message | Tom Lane | 2017-10-31 04:56:40 | Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM |