Re: Truncate logs by max_log_size

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kirill Gavrilov <diphantxm(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Truncate logs by max_log_size
Date: 2026-02-05 11:53:22
Message-ID: 95e3c93f-3b74-41c4-a7f7-63c7ae456a88@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2026-02-05 12:13:46 Re: pg_stat_io_histogram
Previous Message Rahila Syed 2026-02-05 11:15:39 Re: Fix pg_stat_get_backend_wait_event() for aux processes