On 2019-Apr-07, Justin Pryzby wrote:
> [...] Since I've been using log_statement=all, and not
> log_min_duration_statement, I don't have a strong opinion about it.
Ah, so your plan for this in production is to use the sample-based
logging facilities, I see! Did you get Adrien a beer already?
--
Hi,
Thanks both for thinking about this.
On Fri, Apr 05, 2019 at 06:16:38PM -0700, Andres Freund wrote:
> On 2019-04-04 16:01:26 -0300, Alvaro Herrera wrote:
> > Also, if you parse once and bind/execute many times, IMO the statement
> > should be logged exactly once. I think you could that with
Hi,
On 2019-04-04 16:01:26 -0300, Alvaro Herrera wrote:
> Also, if you parse once and bind/execute many times, IMO the statement
> should be logged exactly once. I think you could that with the flag I
> propose.
I'm not actually sure I buy this. Consider e.g. log analysis for
workloads with lon
On Thu, Apr 04, 2019 at 03:07:04PM -0300, Alvaro Herrera wrote:
> which does not look good -- the statement is nowhere to be seen. The commit
> message quotes this as desirable output:
Good catch.
Unnamed statements sent behind the scenes by pqExecParams weren't being logged.
I specifically han
On 2019-Apr-04, Alvaro Herrera wrote:
> I think we could improve on this by setting a "logged" flag in the
> portal; if the Parse logs the statement, then don't include the
> statement in further lines, otherwise do.
Also: I think such a flag could help the case of a query that takes
long enough
On 2019-Apr-04, Alvaro Herrera wrote:
> However, turning duration logging off and using log_statement=all, this is
> what
> I get:
>
> 2019-04-04 14:58:42.564 -03 [31685] LOG: statement: SET search_path =
> testlibpq3
> 2019-04-04 14:58:42.565 -03 [31685] LOG: execute
> 2019-04-04 14:58:42.5
On 2019-Mar-04, Justin Pryzby wrote:
> 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". :)
Some digging turned up that the function you're re
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 thi
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.
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 discussio
On Mon, Mar 04, 2019 at 06:53:31PM +0300, Arthur Zakirov wrote:
> Hello Justin,
>
> On 27.02.2019 21:06, Justin Pryzby wrote:
> >I'm attaching a v2 patch which avoids repeated logging of PREPARE, rather
> >than
> >making such logs conditional on log_error_verbosity=VERBOSE, since
> >log_error_ver
Hello Justin,
On 27.02.2019 21:06, Justin Pryzby wrote:
I'm attaching a v2 patch which avoids repeated logging of PREPARE, rather than
making such logs conditional on log_error_verbosity=VERBOSE, since
log_error_verbosity is documented to control whether these are output:
DETAIL/HINT/QUERY/CONTE
On Fri, Feb 15, 2019 at 08:57:04AM -0600, Justin Pryzby wrote:
> I propose that the prepared statement associated with an EXECUTE should be
> included in log "DETAIL" only when log_error_verbosity=VERBOSE, for both SQL
> EXECUTE and PQexecPrepared (if at all). I'd like to be able to continue
> log
Sigh, resending to -hackers for real.
On Fri, Feb 08, 2019 at 07:29:53AM -0600, Justin Pryzby wrote:
> A couple months ago, I implemented prepared statements for PyGreSQL. While
> updating our application in advance of their release with that feature, I
> noticed that our query logs were several
14 matches
Mail list logo
