Re: Truncate logs by max_log_size

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

From: Jim Jones <jim.jones@uni-muenster.de>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Fujii Masao <masao.fujii@gmail.com>, 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-04-03T21:59:48Z
Lists: pgsql-hackers

Attachments

Hi Kirill

On 20/03/2026 18:33, Kirill Reshke wrote:
> We discussed this patch off-list with Andrey @x4mmm in sight of
> CVE-2026-2006. Looks like this patch is not vulnerable, and its use of
> pg_mbcliplen are correct.

Thanks for checking!

I spent some time revisiting this patch today and realised that it only
applied truncation in exec_simple_query. I believe the original intent
of this feature was to cover other paths as well, so I added the same
logic in exec_execute_message (which handles log_statement logging for
the extended query protocol), and in exec_parse_message and
exec_bind_message (which log statement text when
log_min_duration_statement fires).

v9 attached.

Thoughts on this approach?

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.