Re: Re: query logging of prepared statements

From: David Steele <david(at)pgmasters(dot)net>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: query logging of prepared statements
Date: 2019-03-20 10:46:00
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-general 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?


In response to


Browse pgsql-general by date

  From Date Subject
Next Message Hendrickx Pablo 2019-03-20 11:14:18 Re: WSL (windows subsystem on linux) users will need to turn fsync off as of 11.2
Previous Message Thomas Kellerer 2019-03-20 10:44:38 Re: Postgres Enhancement Request

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2019-03-20 10:50:04 Re: Re: A separate table level option to control compression
Previous Message Fred .Flintstone 2019-03-20 10:43:24 Re: PostgreSQL pollutes the file system