public inbox for [email protected]
help / color / mirror / Atom feedFrom: Fujii Masao <[email protected]>
To: Jim Jones <[email protected]>
Cc: Maxym Kharchenko <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Kirill Gavrilov <[email protected]>
Cc: Andrey M. Borodin <[email protected]>
Cc: Euler Taveira <[email protected]>
Cc: [email protected]
Subject: Re: Truncate logs by max_log_size
Date: Sat, 4 Jul 2026 00:46:46 +0900
Message-ID: <CAHGQGwHhtcMH2YY9bo=qkZWLDkN7DBiHJ0g2Xja8eb6OfVkVUA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CALdSSPh6i4mDZ7TLy7dibSfmDQkzFt5NTqv_QrnhPOFEm2xseg@mail.gmail.com>
<[email protected]>
<CAHGQGwGEd=PpVWDd05bYM8F6mnxcSNmWL2Ei8JCf5azZSJnYJA@mail.gmail.com>
<[email protected]>
<CAHGQGwEc5Dn5KFU04sDp0Kyai2Te5yTuni3QW7pc2a3=343tJQ@mail.gmail.com>
<[email protected]>
<CAHGQGwGVxV1YbtLCT+q1yHejBKjLz7L+8r3WJMW=72SDJFW27g@mail.gmail.com>
<CACsxBjB5+HLw6jJ17qR5vSg+kBb2G5ACSbd_ytZ0HvvD22JqkQ@mail.gmail.com>
<CAHGQGwFYxCVmL4Bvm61bUW+WUi+YXFHzXo9hFEoSgYT1=fU-+w@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CAHGQGwHJHCi=4zEyMc4GJWPC9-oQZHj+9kncxS2442V9PXGgoQ@mail.gmail.com>
<[email protected]>
<CAHGQGwFOV+7nOdfoO=kfVH=-fRA9aQE1YcHHLYty3nfQ9rQ4RA@mail.gmail.com>
<[email protected]>
On Fri, Jul 3, 2026 at 4:34 PM Jim Jones <[email protected]> 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);
Regards,
--
Fujii Masao
view thread (15+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Truncate logs by max_log_size
In-Reply-To: <CAHGQGwHhtcMH2YY9bo=qkZWLDkN7DBiHJ0g2Xja8eb6OfVkVUA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox