Horton

Re: Query generates infinite loop

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Richard Wesley <richard@duckdblabs.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-04-20T16:53:33Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revert "Disallow infinite endpoints in generate_series() for timestamps."

  2. Disallow infinite endpoints in generate_series() for timestamps.

Hi

st 20. 4. 2022 v 18:42 odesílatel Richard Wesley <richard@duckdblabs.com>
napsal:

> Hi All -
>
> I was implementing the infinity time constants in DuckDB when I ran into
> an infinite loop. It seems that PG has the same problem for the same reason
> (adding an interval to an infinite timestamp produces the same timestamp,
> so the increment operation never goes anywhere.)  Here is the query:
>
>    1.
>
>    select COUNT(*) FROM generate_series('-infinity'::TIMESTAMP, 'epoch'::TIMESTAMP, INTERVAL '1 DAY');
>
>
>
> This seems like a DoS great attack, so we are disallowing infinities as
> bounds for both table and scalar series generation. As an upper bound, it
> eventually gives an error, so it seems  there is not much utility anyway.
>

There are more ways to achieve the same effect. The protection is safe
setting of temp_file_limit

2022-04-20 09:59:54) postgres=# set temp_file_limit to '1MB';
SET
(2022-04-20 18:51:48) postgres=# select COUNT(*)
FROM generate_series('-infinity'::TIMESTAMP, 'epoch'::TIMESTAMP, INTERVAL
'1 DAY');
ERROR:  temporary file size exceeds temp_file_limit (1024kB)
(2022-04-20 18:51:50) postgres=#

Regards

Pavel



>
> Met vriendelijke groet, best regards, mit freundlichen Grüßen,
>
> *Richard Wesley*
> Group-By Therapist
> richard@duckdblabs.com
>
>
>
>
>