Re: Underscore in positional parameters?

From: Erik Wienhold <ewie(at)ewie(dot)name>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Underscore in positional parameters?
Date: 2024-05-20 13:59:30
Message-ID: a7811498-8570-482f-a8e9-d79bc55eb256@ewie.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-05-20 05:02 +0200, Tom Lane wrote:
> Erik Wienhold <ewie(at)ewie(dot)name> writes:
> > On 2024-05-20 03:26 +0200, jian he wrote:
> >> /* Check parameter number is in range */
> >> if (paramno <= 0 || paramno > MaxAllocSize / sizeof(Oid))
> >> ereport(ERROR, ...
>
> > Yes, it makes sense to show the upper bound. How about a hint such as
> > "Valid parameters range from $%d to $%d."?
>
> I kind of feel like this upper bound is ridiculous. In what scenario
> is parameter 250000000 not a mistake, if not indeed somebody trying
> to break the system?
>
> The "Bind" protocol message only allows an int16 parameter count,
> so rejecting parameter numbers above 32K would make sense to me.

Agree. I was already wondering upthread why someone would use that many
parameters.

Out of curiosity, I checked if there might be an even lower limit. And
indeed, max_stack_depth puts a limit due to some recursive evaluation:

ERROR: stack depth limit exceeded
HINT: Increase the configuration parameter "max_stack_depth" (currently 2048kB), after ensuring the platform's stack depth limit is adequate.

Attached is the stacktrace for EXECUTE on HEAD (I snipped most of the
recursive frames).

Running \bind, PREPARE, and EXECUTE with following number of parameters
works as expected, although the number varies between releases which is
not ideal IMO. The commands hit the stack depth limit for #Params+1.

Version Command #Params
----------------- ------- -------
HEAD (18cbed13d5) \bind 4365
HEAD (18cbed13d5) PREPARE 8182
HEAD (18cbed13d5) EXECUTE 4363
16.2 \bind 3968
16.2 PREPARE 6889
16.2 EXECUTE 3966

Those are already pretty large numbers in my view (compared to the 100
parameters that we accept at most for functions). And I guess nobody
complained about those limits yet, or they just increased
max_stack_depth.

The Python script to generate the test scripts:

import sys
n_params = 1 << 16
if len(sys.argv) > 1:
n_params = min(n_params, int(sys.argv[1]))
params = '+'.join(f'${i+1}::int' for i in range(n_params))
bind_vals = ' '.join('1' for _ in range(n_params))
exec_vals = ','.join('1' for _ in range(n_params))
print(fr"SELECT {params} \bind {bind_vals} \g")
print(f"PREPARE p AS SELECT {params};")
print(f"EXECUTE p ({exec_vals});")

--
Erik

Attachment Content-Type Size
stacktrace-EXECUTE-18cbed13d5.txt text/plain 9.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2024-05-20 14:14:50 Re: libpq compression (part 3)
Previous Message Masahiko Sawada 2024-05-20 13:40:32 Re: PostgreSQL 17 Beta 1 release announcement draft