Re: Truncate logs by max_log_size

Hi Fujii

On 08/04/2026 18:18, Fujii Masao wrote:
> + If greater than zero, each statement written to the server log
> + is truncated to at most this many bytes.
>
> It would be good to clarify which query logging this parameter affects.
> As I understand it, it applies only to statements logged by log_statement and
> log_min_duration_statement, and not to statements included in other messages
> (e.g., errors). Is that correct?

Agreed. Changed text to:

If greater than zero, each statement logged by <xref
linkend="guc-log-statement"/> or <xref
linkend="guc-log-min-duration-statement"/> is truncated to at most this
many bytes. A value of zero causes statements to be logged with an empty
body. <literal>-1</literal> (the default) logs statements in full. If
this value is specified without units, it is taken as bytes. Only
superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.

> + truncated_query = truncate_query_log(query_string);
> + query_log = truncated_query ? truncated_query : query_string;
>
> In the patch, truncate_query_log() is called unconditionally in
> exec_simple_query(), even when the query isn't logged. This adds unnecessary
> overhead. It would be better to call it only when logging is actually performed
> (e.g., under check_log_statement() or check_log_duration()).

> + char *truncated_query = NULL;
> + const char *query_log;
>
> In exec_parse_message(), exec_bind_message(), and exec_execute_message(),
> variables like truncated_query can be declared closer to where they are used
> (e.g., inside the check_log_duration() switch case) to improve readability.

Done.

Removed the top-level declarations and unconditional
truncate_query_log() call from all four functions. Truncation is now
performed lazily, with local variables declared inside
check_log_statement and case 2 of check_log_duration.

> + long_desc => '-1 means no truncation.',
>
> +#log_statement_max_length = -1 # max length of logged statements
> + # -1 disables truncation
>
> I like the description like "-1 means log statement in full", which seems
> clearer and easier to understand for users. Thought?

Done.

Changed long_desc and comment in postgresql.conf.sqmple from "-1 means
no truncation" to "-1 means log statement in full"

> Regarding the regression test, testing log_statement_max_length in pg_ctl test
> looks a bit odd to me. It might be better to place it under
> src/test/modules/test_misc, for example?

Done.

Moved tests to:
src/test/modules/test_misc/t/012_log_statement_max_length.pl

Something I just noticed: the command that enables truncation is the
first victim of its own effect.

$ psql postgres
psql (19devel)
Type "help" for help.

postgres=# SET log_min_duration_statement = 0;
SET log_statement_max_length = 20;
SET
SET
postgres=#
\q
$ tail /usr/local/postgres-dev/logfile

2026-04-08 22:17:41.958 CEST [206029] LOG: duration: 0.450 ms
statement: SET log_min_duration_statement = 0;
2026-04-08 22:17:41.958 CEST [206029] LOG: duration: 0.085 ms
statement: SET log_statement_ma

I guess it is technically correct.. just a bit funny :)

Thanks for the thorough review!

Best, Jim