Re: Truncate logs by max_log_size

On Fri, Jul 3, 2026 at 3:47 AM Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> 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