Horton
Menu

Re: Truncate logs by max_log_size

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

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

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.

+1 for 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.

I'll take a look at this.

Another thing that we could adjust is the default/disable value: I
personally find 0 to disable the feature a bit confusing. 0 might be
interpreted as "log 0 bytes", and the user ends up with the full
statement logged. What about -1?

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.