Request a Demo
Home   >   mailing lists

Re: Truncate logs by max_log_size - Mailing list pgsql-hackers

From Maxym Kharchenko
Subject Re: Truncate logs by max_log_size
Date
Msg-id CACsxBjB5+HLw6jJ17qR5vSg+kBb2G5ACSbd_ytZ0HvvD22JqkQ@mail.gmail.com
Whole thread
In response to Re: Truncate logs by max_log_size  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Truncate logs by max_log_size
List pgsql-hackers
Tree view
Hello Fujii-san,

There seems to be an inconsistency in the current patch. When a statement has errors (for example, when it hits a table that does not exist), the full statement is still being logged. 

Similar parameter: `log_parameter_max_length` has a companion `log_parameter_max_length_on_error` to handle this case (commit: 0b34e7d307e6, https://github.com/postgres/postgres/commit/0b34e7d307e6a142ee94800e6d5f3e73449eeffd). 

Should the same treatment be added for `log_statement_max_length`?

Have a nice day,
Maxym Kharchenko

On Fri, Apr 17, 2026 at 6:32 AM Fujii Masao <masao.fujii@gmail.com> wrote:
On Fri, Apr 10, 2026 at 7:36 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
> > I see the patch has been moved to CommitFest PG20-1. Once development for v20
> > starts, I'd like to commit it.
>
>
> Terrific. Thanks!

Thanks for updating the patch! LGTM. Let's wait for next CF for v20 to begin.

Regards,

--
Fujii Masao




pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY