Re: Query generates infinite loop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Richard Wesley <richard(at)duckdblabs(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Query generates infinite loop
Date: 2022-04-20 17:03:45
Message-ID: 2842828.1650474225@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2022-04-20 18:23:43 Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica
Previous Message Pavel Stehule 2022-04-20 16:53:33 Re: Query generates infinite loop

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-04-20 17:16:20 Re: using an end-of-recovery record in all cases
Previous Message Nathan Bossart 2022-04-20 17:02:24 Re: using an end-of-recovery record in all cases