From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
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 13:28:34 |
Message-ID: | 20190320132833.GB2952@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi,
On Wed, Mar 20, 2019 at 02:46:00PM +0400, David Steele wrote:
> >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?
I'm happy to make the behavior configurable, but I'm having trouble believing
many people would want a GUC added for this. But I'd be interested to hear
input on whether it should be configurable, or whether the original "verbose"
logging is desirable to anyone.
This is mostly tangential, but since writing the original patch, I considered
the possibility of a logging GUC which is scales better than log_* booleans:
https://www.postgresql.org/message-id/20190316122422.GR6030%40telsasoft.com
If that idea were desirable, there could be a logging_bit to enable verbose
logging of prepared statements.
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-03-20 13:59:59 | Re: Postgres Enhancement Request |
Previous Message | Thomas Güttler | 2019-03-20 12:20:57 | Re: Performance of ByteA: ascii vs binary |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2019-03-20 13:42:21 | Re: Add exclusive backup deprecation notes to documentation |
Previous Message | Michael Paquier | 2019-03-20 13:00:33 | Re: Add exclusive backup deprecation notes to documentation |