On 02.07.24 10:14, Peter Eisentraut wrote:
> On 19.05.24 16:43, Erik Wienhold wrote:
>> On 2024-05-19 07:00 +0200, Alexander Lakhin wrote:
>>> I encountered anomalies that you address with this patch too.
>>> And I can confirm that it fixes most cases, but there is another one:
>>> SELECT $300000000 \bind 'foo' \g
>>> ERROR: invalid memory alloc request size 1200000000
>>>
>>> Maybe you would find this worth fixing as well.
>>
>> Yes, that error message is not great. In variable_paramref_hook we
>> check paramno > INT_MAX/sizeof(Oid) when in fact MaxAllocSize/sizeof(Oid)
>> is the more appropriate limit to avoid that unspecific alloc size error.
>>
>> Fixed in v4 with a separate patch because it's unrelated to the param
>> number parsing. But it fits nicely into the broader issue on the upper
>> limit for param numbers. Note that $268435455 is still the largest
>> possible param number ((2^30-1)/4) and that we just return a more
>> user-friendly error message for params beyond that limit.
>
> I have committed your two v4 patches.
>
> I made a small adjustment in 0001: I changed the ecpg part to also store
> the result from strtoint() into a local variable before checking for
> error, like you had done in the scan.l part. I think this is a bit
> better style. In 0002 you had a typo in the commit message: MAX_INT
> instead of INT_MAX.
I had to revert the test case from the 0002 patch. It ended up running
some build farm machines out of memory.
