Re: Truncate logs by max_log_size

Jim Jones <jim.jones@uni-muenster.de>

From: Jim Jones <jim.jones@uni-muenster.de>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Maxym Kharchenko <maxymkharchenko@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, Fujii Masao <masao.fujii@oss.nttdata.com>, Kirill Gavrilov <diphantxm@gmail.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Euler Taveira <euler@eulerto.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-07-08T17:02:40Z
Lists: pgsql-hackers

Attachments

Hi Fujii

On 03.07.26 17:46, Fujii Masao wrote:
> On Fri, Jul 3, 2026 at 4:34 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
>> +1
>> Nice additions -- the feature gap is obvious, IMHO.
>>
>> Are you planning to work on it? I'm drowning in work right now and can
>> only jump on it next week.
> 
> I don't have plans to work on those at the moment, so please feel free
> to take them on if you have time!
> 
> 
>> I'm not so sure about this one. At this point, isn't "query" already \0
>> terminated? I'm also wondering if it could affect pg_mbcliplen() down
>> the road, since strnlen() can return a different value
>> (log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN) on large queries --
>> not tested yet.
> 
> Yes, "query" should already be NUL-terminated here. The reason for
> using strnlen() is not to handle an unterminated string, but to avoid
> scanning the entire query when it's very large and we only need to
> know whether it exceeds log_statement_max_length.
> 
> I think it's fine to pass the bounded length to pg_mbcliplen().
> It only needs enough input to find a multibyte-safe clipping point at
> or before log_statement_max_length, i.e., it doesn't need the full
> query length. The extra MAX_MULTIBYTE_CHAR_LEN bytes provide enough
> lookahead to handle a multibyte character boundary correctly.
> 
> - query_len = strlen(query);
> + query_len = strnlen(query,
> + (size_t) log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN);

Attached 0001 addressing the points you made:

* appending ellipsis to the query to indicate truncation (docs and tests
also updated accordingly). A side effect of this change is that setting
the parameter to 0 logs an ellipsis, which is not zero in length, but is
arguably correct, as it indicates that the whole query has been
truncated - just noting.
* use of strnlen to avoid scanning the whole query.
* truncation of prepared statements in DETAIL.

While working on this I noticed some redundant checks to call
truncate_query_log(), e.g. in exec_execute_message():

if (log_statement_max_length >= 0)
	truncated_source = truncate_query_log(sourceText);

truncate_query_log() already returns NULL when query logging is disabled
or when no truncation is needed:

/* Truncation is disabled when the limit is negative */
if (!query || log_statement_max_length < 0)
	return NULL;

So I'd argue that we don't need any checks in the caller.

- char	   *truncated_source = NULL;
-
- if (log_statement_max_length >= 0)
-	truncated_source = truncate_query_log(sourceText);
+ char	   *truncated_source = truncate_query_log(sourceText);

0002 attached does this.

Thoughts?

BTW, should I open a new CF entry for this?

Best, Jim

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix log_statement_max_length test with verbose logs

  2. Add log_statement_max_length GUC to limit logged statement text

  3. Improve user control over truncation of logged bind-parameter values.