Re: Truncate logs by max_log_size

On 05/02/2026 11:22, Álvaro Herrera wrote:
> My only comment at this point is that the proposed GUC name is not
> great.  I think it should be something like log_statement_max_length, or
> something like that.  Reading just the thread subject, people would
> imagine this is about the size of the log file.

Done. GUC changed to log_statement_max_length.

> Another point is that the current patch does strlen() twice on each
> query.  It might be better to do away with need_truncate_query_log() and
> have a single routine that both determines whether the truncation is
> needed and returns the truncated query if it is.  If it returns NULL
> then caller assumes it's not needed.

Done. Now truncate_query_log() returns a palloc'd truncated copy of the
statement if truncation is needed, and NULL otherwise.

== issue with issue with empty STATEMENT ==

This issue was mentioned by Fujii upthread. It is now fixed:

postgres=# SET log_statement TO 'all';
SET
postgres=# SET log_statement_max_length TO 3;
SET
postgres=# SELECT 1/0;
ERROR:  division by zero

Log entries:

2026-02-05 17:54:47.521 CET [570568] LOG:  statement: SEL
2026-02-05 17:54:47.521 CET [570568] ERROR:  division by zero
2026-02-05 17:54:47.521 CET [570568] STATEMENT:  SELECT 1/0;

== default value ==

To be consistent with other parameters, such as
log_parameter_max_length, the default (disabled) value is now -1.

== tests ==

Added new tests for -1 and multi-byte characters.


Best, Jim