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 по дате отправления: