| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Maxym Kharchenko <maxymkharchenko(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-20 08:04:17 |
| Message-ID: | CAHGQGwFYxCVmL4Bvm61bUW+WUi+YXFHzXo9hFEoSgYT1=fU-+w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 18, 2026 at 2:04 AM Maxym Kharchenko
<maxymkharchenko(at)gmail(dot)com> wrote:
>
> 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`?
I think extending log_statement_max_length, or adding something like
log_statement_max_length_on_error, would be a good idea to cover statements
logged on error. However, I think the current patch is good as it stands,
so I'd recommend pursuing that as a separate patch after the current one
is committed.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | SATYANARAYANA NARLAPURAM | 2026-04-20 08:03:18 | Re: [BUG]: WHERE CURRENT OF cursor fail on tables that have virtual generated columns |