From: | Alexey Bashtanov <bashtanov(at)imap(dot)cc> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | alvherre(at)2ndquadrant(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | control max length of parameter values logged |
Date: | 2020-02-07 13:56:52 |
Message-ID: | b10493cc-a399-a03a-67c7-068f2791ee50@imap.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
Patch ba79cb5 (for full discussion see [1]) introduces a feature to log
bind parameter values on error,
which greatly helps to reproduce errors artificially having only server
log -- thanks everyone who
reviewed and improved it!
However, it cuts the values, as some of the reviewers were worried log
could fill up too quickly.
This applies both to the new case of logging parameter values and to the
existing ones due to
log_min_duration_statement or log_statement.
This is a backwards-incompatible change, and also ruins the idea of
reproducible errors -- sorry Tom
I failed to second this idea [2] in time, before the change was pushed.
I personally don't think that we necessarily need to cut the values, we
can rely on the users
being careful when using this feature -- in the same way we trusted them
use similarly dangerous
log_min_duration_statement and especially log_statement for ages. At
least it's better than having
no option to disable it. Alvaro's opinion was different [3]. What do you
think
of adding a parameter to limit max logged parameter length? See patch
attached.
Best, Alex
[1] https://postgr.es/m/0146a67b-a22a-0519-9082-bc29756b93a2@imap.cc
[2] https://postgr.es/m/11425.1575927321%40sss.pgh.pa.us
[3] https://postgr.es/m/20191209200531.GA19848@alvherre.pgsql
Attachment | Content-Type | Size |
---|---|---|
log_parameter_max_length_v001.patch | text/x-patch | 4.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-02-07 14:17:59 | Re: Is custom MemoryContext prohibited? |
Previous Message | Fujii Masao | 2020-02-07 13:09:48 | Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) |