Feedback-ID: i76984098:Fastmail
Message-ID: <4f8c37af-96ed-487d-892c-e4b0fdd662ec@aklaver.com>
Date: Wed, 3 Sep 2025 08:56:22 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Q: limit the length of log file entries?
To: =?UTF-8?Q?Albrecht_Dre=C3=9F?= <albrecht.dress@posteo.de>,
 pgsql-general@lists.postgresql.org
References: <YJI7DQ4I.3WYAVH2R.IWZZPYNU@AP5TCLKO.ZBA47T5B.KHWCFARS>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <YJI7DQ4I.3WYAVH2R.IWZZPYNU@AP5TCLKO.ZBA47T5B.KHWCFARS>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/4f8c37af-96ed-487d-892c-e4b0fdd662ec%40aklaver.com>
Precedence: bulk

On 9/3/25 08:40, Albrecht Dreß wrote:
> Hi all,
> 
> I wonder if it would be possible to limit the length of individual log lines being written to the log file.
> 
> Background:
> I have a PL/PGsql DB function 'addval(_id text, _data bytea) RETURNS VOID'.  When a broken bytea is passed as 2nd parameter, something like
> 
> albrecht@test FEHLER:  ungültige hexadezimale Ziffer: »r« bei Zeichen 28
> albrecht@test ANWEISUNG:  SELECT FROM addval('hopp', '\xbroken')
> 
> is printed in the log file.  This is fine and very helpful in this case, but I have a “friendly user” who transmitted a broken hex string of ~100 KBytes as second parameter, resulting in a log line of this size which is not really readable and when done frequently quickly fills the logs.
> 
> The log settings are, inter alia
> 
> log_parameter_max_length = 256
> log_parameter_max_length_on_error = 256
> log_error_verbosity = TERSE

Did you reload the server after making the above changes?

Did you take a look at output from:

https://www.postgresql.org/docs/current/view-pg-settings.html

for appropriate settings name to see if something is overriding the 
settings you changed?


> 
> but seem to have not the desired effect in this case.

Did it have any effect?

> 
> I use PostgreSQL version 17.6-1.pgdg13+1 on Debian Trixie.
> 
> Thanks in advance for any help,
> Albrecht.


-- 
Adrian Klaver
adrian.klaver@aklaver.com