Re: Truncate logs by max_log_size - Mailing list pgsql-hackers

On 2025/02/03 19:31, Jim Jones wrote:
> Hi Kirill
> 
> On 31.01.25 11:46, Kirill Gavrilov wrote:
>> Sorry for the long silence.  I fixed the indentation and a trailing
>> whitespace. Should look fine now.
> 
> 
> The patch applies cleanly, the documentation is clear, and all tests pass.
> 
> It is possible to change this new parameter session-wise, which is nice!
> 
> postgres=# SET max_log_size TO 7;
> SET
> postgres=# SHOW max_log_size;
>   max_log_size
> --------------
>   7B
> (1 row)
> 
> 
> The default value now is clear and it corresponds to the value set on
> postgresql.conf:
> 
> #max_log_size = 0       # max size of logged statement
> 
> postgres=# SHOW max_log_size;
>   max_log_size
> --------------
>   0
> (1 row)
> 
> 
> Logs are truncated as expected:
> 
> postgres=# SET max_log_size TO 6;
> SET
> postgres=# SELECT length('CALL xyz;');
>   length
> --------
>        9
> (1 row)
> 
> postgres=# CALL xyz;
> ERROR:  syntax error at or near ";"
> LINE 1: CALL xyz;
> 
> 
> log entry:
> 
> 2025-02-03 10:58:19.975 CET [123945] ERROR:  syntax error at or near ";"
> at character 9
> 2025-02-03 10:58:19.975 CET [123945] STATEMENT:  CALL x
> 
> 
> The issue with log entry sizes for queries containing special characters
> was resolved by setting the unit to bytes.
> 
> Overall, everythingLGTM.
> 
> The new status of this patch is: Ready for Committer

Since this patch is marked as ready-for-committer, I started reviewing it.
Basically I like the proposed idea.


When I set log_statement to 'all', max_log_size to 3, and ran "SELECT 1/0",
only the first three bytes of the query were logged by log_statement.
However, no query statement appeared under STATEMENT, as shown below.
Is this a bug?

--------------------------
=# SET log_statement TO 'all';
=# SET max_log_size TO 3;
=# SELECT 1/0;
LOG:  statement: SEL
ERROR:  division by zero
STATEMENT:
--------------------------


When log_replication_commands is enabled, replication commands are logged.
Should max_log_size apply to these logs as well to prevent excessively
large commands from being logged in full?


The parameter name max_log_size seems misleading. It sounds like
it controls the maximum log file size. Would a name like
log_statement_max_length be clearer?


The functions like exec_parse_message(), exec_bind_message(),
and exec_execute_message() may log query statements (e.g., via
log_min_duration_statement), but the patch doesn't seem to
update them to consider max_log_size.


Queries can also be logged in the CONTEXT line, such as when running
"DO $$ BEGIN SELECT 1/0; END $$;", but max_log_size doesn't seem to
apply in this case.


There might be other cases where queries are logged, but the patch
doesn't handle them. I'm not sure we can identify and address all of
them before the feature freeze.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION