Re: Fix overflow in DecodeInterval
Joseph Koshakow <koshy44@gmail.com>
From: Joseph Koshakow <koshy44@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-03T15:23:07Z
Lists: pgsql-hackers
On Sun, Apr 3, 2022 at 3:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I wrote: > > Cool. I've pushed the patch. > > Hmm ... buildfarm's not entirely happy [1][2][3]: > > diff -U3 /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/expected/interval.out /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/results/interval.out > --- /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/expected/interval.out 2022-04-03 04:56:32.000000000 +0000 > +++ /home/nm/farm/gcc64/HEAD/pgsql.build/src/test/regress/results/interval.out 2022-04-03 05:23:00.000000000 +0000 > @@ -1465,7 +1465,7 @@ > LINE 1: select interval 'PT2562047788.1:00:54.775807'; > ^ > select interval 'PT2562047788:01.:54.775807'; > - ERROR: interval field value out of range: "PT2562047788:01.:54.775807" > + ERROR: invalid input syntax for type interval: "PT2562047788:01.:54.775807" > LINE 1: select interval 'PT2562047788:01.:54.775807'; > ^ > -- overflowing with fractional fields - SQL standard format > > What do you make of that? I'm betting that strtod() works a > bit differently on those old platforms, but too tired to > look closer tonight. > > regards, tom lane > > [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2022-04-03%2004%3A56%3A34 > [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2022-04-03%2000%3A51%3A50 > [3] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=anole&dt=2022-04-03%2000%3A32%3A10 I think I know that the issue is. It's with `ParseISO8601Number` and the minutes field "1.". Previously that function parsed the entire field into a single double, so "1." would be parsed into 1.0. Now we try to parse the integer and decimal parts separately. So we first parse "1" into 1 and then fail to "." into anything because it's not a valid decimal. What's interesting is that I believe this syntax, "1.", always would have failed for non-ISO8601 Interval. It was only previously valid with ISO8601 intervals. - Joe Koshakow
Commits
-
Fix portability issues in datetime parsing.
- 591e088dd5b3 15.0 landed
-
Fix overflow hazards in interval input and output conversions.
- e39f99046710 15.0 landed
-
Add a couple more tests for interval input decoding.
- 1b208ebaf14e 15.0 landed