sql: decimal round can DOS the server

[maddyblue]

SELECT round(-0.32096519520627553, -2438602134409251682)

The above query will peg one CPU core at 100% for many minutes until it completes (I have not run it long enough to see how long that is). This is because the implementation of decimal rounding does some quotient remainder calculations that take a while or something.

In any case it's not obvious to me how to handle this, but something should be done since this makes it trivial to shut down a server.

Found with RSG.

[knz]

cc @nvanbenschoten.

[knz]

I think we shouldn't allow abnormally large scales in the 2nd argument to round, and it seems to me that negative scales are meaningless. WDYT?

[RaduBerinde]

Wow, yeah the second argument is the number of decimals, definitely needs to be non-negative. As for large values, I think the operation should be a no-op if the number we are rounding already has less decimals than we want. If adding such a check is easy, I think it's the way to go because we don't need to set a hard limit specifically for round.

[maddyblue]

Postgres' behavior when the 2nd arg is higher than the number of decimals is to append 0s:

# select round(-0.32096519520627553, 100);
                                                  round                                                  
---------------------------------------------------------------------------------------------------------
 -0.3209651952062755300000000000000000000000000000000000000000000000000000000000000000000000000000000000
(1 row)

Notably, though, postgres limits the number of digits after the decimal point to 2000. I'm not sure if that's just with round or with their decimal implementation in general.

---

Upon investigation, this is caused (in cockroach) by the Exp method in decimal. We can easily reproduce this with:

select exp(1845949582::decimal)

Which similarly pegs a core. That query in postgres says:

=# select exp(1845949582::decimal);
ERROR:  argument for function "exp" too big

But I can't find in the source where that error is coming from to see what they do there.

[knz]

FYI the code in pg resides in src/backend/util/adt (numeric.c and float.c).