Re: Truncate logs by max_log_size

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Jim Jones <jim(dot)jones(at)uni-muenster(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 10:22:19
Message-ID: 202602051012.qer26xklakqb@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2026-Feb-05, Jim Jones wrote:

> On 05/02/2026 03:17, Fujii Masao wrote:
> > At least I'm not for now. So please feel free to work on the patch if
> > you'd like!
>
> If nobody is planning to work on this, I can take a look at it next week.

That'd be swell.

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.

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.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2026-02-05 10:25:54 Re: pg_upgrade: fix memory leak in SLRU I/O code
Previous Message Michael Paquier 2026-02-05 10:21:23 Re: Add expressions to pg_restore_extended_stats()