On Fri, Jul 3, 2026 at 3:47 AM Jim Jones <[email protected]> wrote:
>
> Hi Fujii
>
> On 02/07/2026 17:49, Fujii Masao wrote:
> > I reviewed the patch again and made a few additional changes. The updated
> > patch is attached. Barring any objections, I'm thinking to commit it.
>
>
> The changes seem reasonable to me.
> Thanks for taking care of it!
Thanks for the review! I've pushed the patch.
While working on it, I found a few possible follow-up improvements.
(1)
When log_statement is enabled, executing a prepared statement logs the
prepared query in a DETAIL message. For example:
=# SET log_statement_max_length TO 10;
=# PREPARE test AS SELECT * FROM pgbench_accounts WHERE aid = $1;
LOG: statement: PREPARE te
=# EXECUTE test(1);
LOG: statement: EXECUTE te
DETAIL: prepare: PREPARE test AS SELECT * FROM pgbench_accounts
WHERE aid = $1;
Should log_statement_max_length also apply to such query string in the
DETAIL message?
(2)
When a bind parameter is truncated by
log_parameter_max_length, an ellipsis (...) is appended:
=# SET log_parameter_max_length TO 5;
=# SELECT $1::text \bind 'abcdefghijk' \g
LOG: execute <unnamed>: SELECT $1::text
DETAIL: Parameters: $1 = 'abcde...'
Would it make sense for log_statement_max_length to append an
ellipsis as well, so that users can easily tell when a statement has
been truncated?
(3)
+ query_len = strlen(query);
truncate_query_log() uses strlen() only to determine whether the
query exceeds log_statement_max_length. Since the query can be very
large, would it be better to use
strnlen(query, log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN)
instead, to avoid scanning the entire string?
Regards,
--
Fujii Masao
