Hi Maxym, Hi Fujii
On 20/04/2026 10:04, Fujii Masao wrote:
> On Sat, Apr 18, 2026 at 2:04 AM Maxym Kharchenko
> <maxymkharchenko@gmail.com> wrote:
>> Hello Fujii-san,
>>
>> There seems to be an inconsistency in the current patch. When a statement has errors (for example, when it hits a
tablethat does not exist), the full statement is still being logged.
>>
>> Similar parameter: `log_parameter_max_length` has a companion `log_parameter_max_length_on_error` to handle this
case(commit: 0b34e7d307e6, https://github.com/postgres/postgres/
>> commit/0b34e7d307e6a142ee94800e6d5f3e73449eeffd).
Thanks for the input!
It's an interesting idea. However, I am not entirely convinced it
applies to this patch. IIUC log_parameter_max_length_on_error can be
used if you want to see the parameter values (for debugging), which
might contain sensitive information. So it is more like a
security/privacy control?
psql (19devel)
Type "help" for help.
postgres=# SELECT 1/$1
\bind 000
\g
ERROR: division by zero
postgres=# SET log_parameter_max_length_on_error = -1;
SELECT 1/$1
\bind 000
\g
SET
ERROR: division by zero
CONTEXT: unnamed portal with parameters: $1 = '000'
postgres=# SET log_parameter_max_length_on_error = 2;
SELECT 1/$1
\bind 000
\g
SET
ERROR: division by zero
CONTEXT: unnamed portal with parameters: $1 = '00...'
Please correct me if I am wrong, but a statement is not sensitive in the
way parameter values can be. The reason to truncate statements is purely
log size management.
> I think extending log_statement_max_length, or adding something like
> log_statement_max_length_on_error, would be a good idea to cover statements
> logged on error. However, I think the current patch is good as it stands,
> so I'd recommend pursuing that as a separate patch after the current one
> is committed.
+1
Best, Jim
