control max length of parameter values logged - Mailing list pgsql-hackers

From Alexey Bashtanov
Subject control max length of parameter values logged
Date
Msg-id b10493cc-a399-a03a-67c7-068f2791ee50@imap.cc
Whole thread Raw
Responses Re: control max length of parameter values logged  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Next
From: Robert Haas
Date:
Subject: Re: Is custom MemoryContext prohibited?