Hi Maxym, Hi Fujii On 20/04/2026 10:04, Fujii Masao wrote: > On Sat, Apr 18, 2026 at 2:04 AM Maxym Kharchenko > <[email protected]> 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 table that 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
