Message-ID: <3c40c38c-29fe-4e24-944b-6fe90ade9ffa@uni-muenster.de>
Date: Sat, 4 Jul 2026 13:01:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Truncate logs by max_log_size
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Maxym Kharchenko <maxymkharchenko@gmail.com>,
 Kirill Reshke <reshkekirill@gmail.com>, =?UTF-8?Q?=C3=81lvaro_Herrera?=
 <alvherre@kurilemu.de>, 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
References: <202602051012.qer26xklakqb@alvherre.pgsql>
 <CAHGQGwGEd=PpVWDd05bYM8F6mnxcSNmWL2Ei8JCf5azZSJnYJA@mail.gmail.com>
 <81297eea-8a5c-4cdc-9c49-0524e3968b62@uni-muenster.de>
 <CAHGQGwEc5Dn5KFU04sDp0Kyai2Te5yTuni3QW7pc2a3=343tJQ@mail.gmail.com>
 <e687b0ab-86a0-4a13-9518-6f02a4668082@uni-muenster.de>
 <CAHGQGwGVxV1YbtLCT+q1yHejBKjLz7L+8r3WJMW=72SDJFW27g@mail.gmail.com>
 <CACsxBjB5+HLw6jJ17qR5vSg+kBb2G5ACSbd_ytZ0HvvD22JqkQ@mail.gmail.com>
 <CAHGQGwFYxCVmL4Bvm61bUW+WUi+YXFHzXo9hFEoSgYT1=fU-+w@mail.gmail.com>
 <a48cfb9e-8af7-4de7-b110-b1ef02042f2e@uni-muenster.de>
 <a474927a-a918-4a1f-9b9e-b7847a78c14b@uni-muenster.de>
 <67fcc68a-fce0-42b8-863f-8db5509d1790@uni-muenster.de>
 <CAHGQGwHJHCi=4zEyMc4GJWPC9-oQZHj+9kncxS2442V9PXGgoQ@mail.gmail.com>
 <93f10aa2-4c04-45dd-9810-98c7d2dd9b34@uni-muenster.de>
 <CAHGQGwFOV+7nOdfoO=kfVH=-fRA9aQE1YcHHLYty3nfQ9rQ4RA@mail.gmail.com>
 <c34ce4e1-3f46-4c9d-a092-eb30ed463c99@uni-muenster.de>
 <CAHGQGwHhtcMH2YY9bo=qkZWLDkN7DBiHJ0g2Xja8eb6OfVkVUA@mail.gmail.com>
Content-Language: en-US, de-DE
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAHGQGwHhtcMH2YY9bo=qkZWLDkN7DBiHJ0g2Xja8eb6OfVkVUA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/3c40c38c-29fe-4e24-944b-6fe90ade9ffa%40uni-muenster.de>
Precedence: bulk

On 03/07/2026 17:46, Fujii Masao wrote:
> On Fri, Jul 3, 2026 at 4:34 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
>> +1
>> Nice additions -- the feature gap is obvious, IMHO.
>>
>> Are you planning to work on it? I'm drowning in work right now and can
>> only jump on it next week.
> I don't have plans to work on those at the moment, so please feel free
> to take them on if you have time!
> 
> 
>> I'm not so sure about this one. At this point, isn't "query" already \0
>> terminated? I'm also wondering if it could affect pg_mbcliplen() down
>> the road, since strnlen() can return a different value
>> (log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN) on large queries --
>> not tested yet.
> Yes, "query" should already be NUL-terminated here. The reason for
> using strnlen() is not to handle an unterminated string, but to avoid
> scanning the entire query when it's very large and we only need to
> know whether it exceeds log_statement_max_length.
> 
> I think it's fine to pass the bounded length to pg_mbcliplen().
> It only needs enough input to find a multibyte-safe clipping point at
> or before log_statement_max_length, i.e., it doesn't need the full
> query length. The extra MAX_MULTIBYTE_CHAR_LEN bytes provide enough
> lookahead to handle a multibyte character boundary correctly.
> 
> - query_len = strlen(query);
> + query_len = strnlen(query,
> + (size_t) log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN);

All right, thanks for the explanation.
I'll give it a try next week.

Have a nice weekend!

Best, Jim