Re: Re: query logging of prepared statements - Mailing list pgsql-hackers

From David Steele
Subject Re: Re: query logging of prepared statements
Date
Msg-id 2da70a91-2a22-9d78-84ba-cba4b71c7541@pgmasters.net
Whole thread Raw
In response to Re: query logging of prepared statements  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Responses Re: Re: query logging of prepared statements
List pgsql-hackers
Hi Justin,

On 3/5/19 2:30 PM, Arthur Zakirov wrote:
> On 04.03.2019 21:31, Justin Pryzby wrote:
>> It wasn't intentional.  Find attached v3 patch which handles that case,
>> by removing the 2nd call to errdetail_execute() ; since it's otherwise 
>> unused,
>> so remove that function entirely.
> 
> Thank you.
> 
>> Thanks for reviewing.  I'm also interested in discussion about whether 
>> this
>> change is undesirable for someone else for some reason ?  For me, the 
>> existing
>> output seems duplicative and "denormalized".  :)
> 
> I perfectly understand your use case. I agree, it is duplicated. But I 
> think some people may want to see it at every EXECUTE, if they don't 
> want to grep for the prepared statement body which was logged earlier.
> 
> I think it would be good to give possibility to configure this behavior. 
> At first version of your patch you relied on log_error_verbosity GUC. 
> I'm not sure that this variables is suitable for configuring visibility 
> of prepared statement body in logs, because it sets more general 
> behavior. Maybe it would be better to introduce some new GUC variable if 
> the community don't mind.
Thoughts on this?

Regards,
-- 
-David
david@pgmasters.net


pgsql-hackers by date:

Previous
From: "Fred .Flintstone"
Date:
Subject: Re: PostgreSQL pollutes the file system
Next
From: David Steele
Date:
Subject: Re: Re: A separate table level option to control compression