Re: Truncate logs by max_log_size

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Kirill Gavrilov <diphantxm(at)gmail(dot)com>
Cc: 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: 2024-12-02 10:08:55
Message-ID: d300f773-0bfa-4925-924b-f5959d47e254@uni-muenster.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.11.24 21:57, Kirill Gavrilov wrote:
> Same thing applies to log_parameter_max_length, for example.
>
> postgres=# set log_parameter_max_length = '1foo';
> ERROR:  invalid value for parameter "log_parameter_max_length": "1foo"
> HINT:  Valid units for this parameter are "B", "kB", "MB", "GB", and "TB".
> postgres=# set log_parameter_max_length = '1TB';
> ERROR:  invalid value for parameter "log_parameter_max_length": "1TB"
> HINT:  Value exceeds integer range. 
>
> I think we can leave it as is.

I see. So I guess it is out of scope to change this message here.

Small nitpicks:

1) The indentation of the comment at postgresql.conf.sample is a little
bit off

#max_log_size = 0                 # max size of logged statement
                    # 0 disables the feature

IMHO it looks better like this:

#max_log_size = 0   # max size of logged statement
                    # 0 disables the feature

2) You introduced a trailing whitespace at L34 (Not critical :))

+        Zero disables the setting.

It happens to me all the time, so I usually try to apply my patches in a
clean branch just to make sure I didn't miss anything.

Other than that, I have nothing more to add at this point.

Thanks

--
Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-12-02 10:10:56 meson missing test dependencies
Previous Message Amit Kapila 2024-12-02 09:59:56 Re: Memory leak in WAL sender with pgoutput (v10~)