| 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: | Whole Thread | Raw Message | 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 | 
| 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 |