Horton

Re: Query generates infinite loop

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Richard Wesley <richard@duckdblabs.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-04-20T17:03:45Z
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.

Pavel Stehule <pavel.stehule@gmail.com> writes:
> st 20. 4. 2022 v 18:42 odesílatel Richard Wesley <richard@duckdblabs.com>
> napsal:
>> 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

Well, there are any number of ways to DOS a database you can issue
arbitrary queries to.  For instance, cross joining a number of very
large tables.  So I'm not excited about that aspect of it.  Still,
it's true that infinities as generate_series endpoints are going
to work pretty oddly, so I agree with the idea of forbidding 'em.

Numeric has infinity as of late, so the numeric variant would
need to do this too.

I think we can allow infinity as the step, though.

			regards, tom lane