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
- v1-0001-Improve-log_statement_max_length-truncation.patch (text/x-patch) patch v1-0001
- v1-0002-Simplify-callers-of-truncate_query_log.patch (text/x-patch) patch v1-0002
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 →
-
Fix log_statement_max_length test with verbose logs
- 9bfbf5bf6190 master landed
-
Add log_statement_max_length GUC to limit logged statement text
- c8bd8387c27a master landed
-
Improve user control over truncation of logged bind-parameter values.
- 0b34e7d307e6 13.0 cited