From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joseph Koshakow <koshy44(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
Subject: | Re: Remove dependence on integer wrapping |
Date: | 2024-06-13 04:00:00 |
Message-ID: | 31ad2cd1-db94-bdb3-f91a-65ffdb4bef95@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
10.06.2024 04:57, Tom Lane wrote:
> BTW, while I approve of trying to get rid of our need for -fwrapv,
> I'm quite scared of actually doing it. Whatever cases you may have
> discovered by running the regression tests will be at best the
> tip of the iceberg. Is there any chance of using static analysis
> to find all the places of concern?
Let me remind you of bug #18240. Yes, that was about float8, but with
-ftrapv we can get into the trap with:
SELECT 1_000_000_000::money * 1_000_000_000::int;
server closed the connection unexpectedly
Also there are several trap-producing cases with date types:
SELECT to_date('100000000', 'CC');
SELECT to_timestamp('1000000000,999', 'Y,YYY');
SELECT make_date(-2147483648, 1, 1);
And one more with array...
CREATE TABLE t (ia int[]);
INSERT INTO t(ia[2147483647:2147483647]) VALUES ('{}');
I think it's not the whole iceberg too.
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2024-06-13 04:40:24 | Re: Logical Replication of sequences |
Previous Message | Amit Kapila | 2024-06-13 03:59:03 | Re: 001_rep_changes.pl fails due to publisher stuck on shutdown |