On Mon, Jan 25, 2016 at 6:55 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On 01/25/2016 07:22 AM, Tom Lane wrote:
>>
>> Michael Paquier <michael.paquier@gmail.com> writes:
>>>
>>> On Mon, Jan 25, 2016 at 3:00 PM, Corey Huinker <corey.huinker@gmail.com>
>>> wrote:
>>>>
>>>> One thing I discovered in doing this patch is that if you do a timestamp
>>>> generate_series involving infinity....it tries to do it. I didn't wait
>>>> to
>>>> see if it finished.
>>
>>
>>> Well, I would think that this is a bug that we had better address and
>>> backpatch. It does not make much sense to use infinity for timestamps,
>>> but letting it run infinitely is not good either.
>>
>>
>> Meh. Where would you cut it off? AD 10000000000? A few zeroes either
>> way doesn't really make much difference.
>
>
> Why cut off? Why not to check if any of the input values is an infinity and
> simply error out in that case?
That's exactly my point.
>> If it didn't respond to SIGINT, that would be an issue, but
>> otherwise this doesn't seem much more exciting than any other way to
>> create a query that will run longer than you want to wait.
>
> I disagree. Sure, it's possible to construct queries that take forever, but
> that's difficult (or impossible) to detect at query start. I don't think
> that means we should not guard against cases that are provably infinite and
> can't possibly work.
>
> Imagine for example a script that in some rare cases passes happens to pass
> infinity into generate_series() - in that case I'd much rather error out
> than wait till the end of the universe.
Or wait until all the memory of the system is consumed. In the worst
case the OOM killer would come by, say 'Hi!' and do the police work,
but that's not cool either.
--
Michael
