On 02.07.24 16:14, Tom Lane wrote:
Peter Eisentraut <pe...@eisentraut.org> writes:
I had to revert the test case from the 0002 patch. It ended up running
some build farm machines out of memory.
That ties into what I said upthread: why are we involving MaxAllocSize
in this at all? The maximum parameter number you can actually use in
extended queries is 65535 (because 16-bit fields), and I can't see a
good reason to permit more.
There are arguably a few things that could be done in this area of code
to improve it, like consistently using int16 and strtoint16 and so on
for parameter numbers. But that's a different project.
The change here was merely to an existing check that apparently wanted
to avoid some kind of excessive memory allocation but did so
ineffectively by checking against INT_MAX, which had nothing to do with
how the memory allocation checking actually works. The fixed code now
avoids the error for "invalid memory alloc request size", but of course
it can still fail if the OS does not have enough memory.
