Re: Underscore in positional parameters?

Поиск
Список
Период
Сортировка
От Erik Wienhold
Тема Re: Underscore in positional parameters?
Дата
Msg-id a7811498-8570-482f-a8e9-d79bc55eb256@ewie.name
обсуждение исходный текст
Ответ на Re: Underscore in positional parameters?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2024-05-20 05:02 +0200, Tom Lane wrote:
> Erik Wienhold <ewie@ewie.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
stackdepth 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: PostgreSQL 17 Beta 1 release announcement draft
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: libpq compression (part 3)