|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
>> so remove that function entirely.
> Thank you.
>> Thanks for reviewing. I'm also interested in discussion about whether
>> change is undesirable for someone else for some reason ? For me, the
>> 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?
|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|
|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|