MIME-Version: 1.0
References: <202602051012.qer26xklakqb@alvherre.pgsql>
 <86088202-7ce1-4361-b4ee-8703b9e64dd6@uni-muenster.de>
 <061c739f-1ebd-41e8-b49e-8159908f644c@uni-muenster.de>
 <CALdSSPh6i4mDZ7TLy7dibSfmDQkzFt5NTqv_QrnhPOFEm2xseg@mail.gmail.com>
 <0514f233-5f77-469b-88c3-e8eb7487afc2@uni-muenster.de>
 <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>
In-Reply-To: <93f10aa2-4c04-45dd-9810-98c7d2dd9b34@uni-muenster.de>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Fri, 3 Jul 2026 09:56:04 +0900
Message-ID: 
 <CAHGQGwFOV+7nOdfoO=kfVH=-fRA9aQE1YcHHLYty3nfQ9rQ4RA@mail.gmail.com>
Subject: Re: Truncate logs by max_log_size
To: Jim Jones <jim.jones@uni-muenster.de>
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHGQGwFOV%2B7nOdfoO%3DkfVH%3D-fRA9aQE1YcHHLYty3nfQ9rQ4RA%40mail.gmail.com>
Precedence: bulk

On Fri, Jul 3, 2026 at 3:47=E2=80=AFAM Jim Jones <jim.jones@uni-muenster.de=
> wrote:
>
> Hi Fujii
>
> On 02/07/2026 17:49, Fujii Masao wrote:
> > I reviewed the patch again and made a few additional changes. The updat=
ed
> > patch is attached. Barring any objections, I'm thinking to commit it.
>
>
> The changes seem reasonable to me.
> Thanks for taking care of it!

Thanks for the review! I've pushed the patch.

While working on it, I found a few possible follow-up improvements.

(1)
When log_statement is enabled, executing a prepared statement logs the
prepared query in a DETAIL message. For example:

    =3D# SET log_statement_max_length TO 10;
    =3D# PREPARE test AS SELECT * FROM pgbench_accounts WHERE aid =3D $1;
    LOG:  statement: PREPARE te
    =3D# EXECUTE test(1);
    LOG:  statement: EXECUTE te
    DETAIL:  prepare: PREPARE test AS SELECT * FROM pgbench_accounts
WHERE aid =3D $1;

Should log_statement_max_length also apply to such query string in the
DETAIL message?

(2)
When a bind parameter is truncated by
log_parameter_max_length, an ellipsis (...) is appended:

    =3D# SET log_parameter_max_length TO 5;
    =3D# SELECT $1::text \bind 'abcdefghijk' \g
    LOG:  execute <unnamed>: SELECT $1::text
    DETAIL:  Parameters: $1 =3D 'abcde...'

Would it make sense for log_statement_max_length to append an
ellipsis as well, so that users can easily tell when a statement has
been truncated?

(3)
+ query_len =3D strlen(query);

truncate_query_log() uses strlen() only to determine whether the
query exceeds log_statement_max_length. Since the query can be very
large, would it be better to use

    strnlen(query, log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN)

instead, to avoid scanning the entire string?

Regards,

--=20
Fujii Masao