| From: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
|---|---|
| To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, 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-03 21:59:48 |
| Message-ID: | 0514f233-5f77-469b-88c3-e8eb7487afc2@uni-muenster.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Kirill
On 20/03/2026 18:33, Kirill Reshke wrote:
> We discussed this patch off-list with Andrey @x4mmm in sight of
> CVE-2026-2006. Looks like this patch is not vulnerable, and its use of
> pg_mbcliplen are correct.
Thanks for checking!
I spent some time revisiting this patch today and realised that it only
applied truncation in exec_simple_query. I believe the original intent
of this feature was to cover other paths as well, so I added the same
logic in exec_execute_message (which handles log_statement logging for
the extended query protocol), and in exec_parse_message and
exec_bind_message (which log statement text when
log_min_duration_statement fires).
v9 attached.
Thoughts on this approach?
Best, Jim
| Attachment | Content-Type | Size |
|---|---|---|
| v9-0001-Add-log_statement_max_length-GUC-to-limit-logged-.patch | text/x-patch | 14.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Daniel Gustafsson | 2026-04-03 21:46:09 | Re: Changing the state of data checksums in a running cluster |