Re: Truncate logs by max_log_size

From: Maxym Kharchenko <maxymkharchenko(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kirill Gavrilov <diphantxm(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: 2026-04-17 17:03:49
Message-ID: CACsxBjB5+HLw6jJ17qR5vSg+kBb2G5ACSbd_ytZ0HvvD22JqkQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(dot)fujii(at)gmail(dot)com> wrote:

> On Fri, Apr 10, 2026 at 7:36 AM Jim Jones <jim(dot)jones(at)uni-muenster(dot)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
>
>
>
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message SATYANARAYANA NARLAPURAM 2026-04-17 17:40:39 Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY
Previous Message Antonin Houska 2026-04-17 15:45:52 Re: [PATCH] Compressed TOAST data corruption with REPACK CONCURRENTLY