Applied.
---
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > a null for the prepare string. Also, rather than change the API for
> > > > pg_parse_query(), I use a global
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > a null for the prepare string. Also, rather than change the API for
> > > pg_parse_query(), I use a global variable that I check after the
> > > function call.
> >
> > This is horribly ugly and will doubtless lead to pfree cr
Tom Lane wrote:
> Bruce Momjian writes:
> >> What was the point again?
>
> > Simon said that the EXECUTE is pretty useless for debugging unless we
> > show the prepare query. His patch shows the prepare query for
> > client-side prepare, but not for server side when using the
> > PREPARE/EXECUTE
Bruce Momjian writes:
>> What was the point again?
> Simon said that the EXECUTE is pretty useless for debugging unless we
> show the prepare query. His patch shows the prepare query for
> client-side prepare, but not for server side when using the
> PREPARE/EXECUTE commands --- seems we should
Tom Lane wrote:
> Bruce Momjian writes:
> > a null for the prepare string. Also, rather than change the API for
> > pg_parse_query(), I use a global variable that I check after the
> > function call.
>
> This is horribly ugly and will doubtless lead to pfree crashes. What
Agreed, it needs work
Tom Lane wrote:
> Bruce Momjian writes:
> > a null for the prepare string. Also, rather than change the API for
> > pg_parse_query(), I use a global variable that I check after the
> > function call.
>
> This is horribly ugly and will doubtless lead to pfree crashes. What
> was the point again?
Bruce Momjian writes:
> a null for the prepare string. Also, rather than change the API for
> pg_parse_query(), I use a global variable that I check after the
> function call.
This is horribly ugly and will doubtless lead to pfree crashes. What
was the point again?
rega
OK, new patch. I used portal->sourceText as Tom suggested, and checked
for NULL before printing. I put the original query in brackets in the
log output, patch attached.
I would like to also do this for server-side EXECUTE. I am have
attached a second version that does it by using the existing
On Sun, May 15, 2005 at 10:48:47PM +0100, Simon Riggs wrote:
> Somebody out there is too modest to point out how often it is that I
> only dot the "I"s they have left for me...
Funny you mention it. Remember that shared row locking project of mine
-- guess what. The idea comes from Bruce (his
On Sun, 2005-05-15 at 13:29 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sat, 2005-05-14 at 16:55 -0400, Bruce Momjian wrote:
> >> One thing you did was to log debug_query_string, but I don't see how
> >> that could be the right value.
>
> > I used the debug_query_string
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2005-05-14 at 16:55 -0400, Bruce Momjian wrote:
>> One thing you did was to log debug_query_string, but I don't see how
>> that could be the right value.
> I used the debug_query_string because even in the EXEC case it is set,
> so that the SQL sta
On Sat, 2005-05-14 at 16:55 -0400, Bruce Momjian wrote:
> Uh, I am confused by this. Your code test is:
>
> + if ((log_statement == LOGSTMT_ALL && save_log_duration) ||
> + save_log_min_duration_statement)
> + gettimeofday(&start_t, NULL);
>
> First, log_min_durat
Tom Lane wrote:
> Bruce Momjian writes:
> > One thing you did was to log debug_query_string, but I don't see how
> > that could be the right value. I assume it would be empty in a
> > client-side execute, or be the previous query. I instead used "EXECUTE
> > portal_name" because that is what we
Bruce Momjian writes:
> One thing you did was to log debug_query_string, but I don't see how
> that could be the right value. I assume it would be empty in a
> client-side execute, or be the previous query. I instead used "EXECUTE
> portal_name" because that is what we are passed from the client
Simon Riggs wrote:
> Following patch is a minor addition to postgres.c that allows the two
> existing statement logging techniques to work with V3 exec. This then
> allows statement logging with PostgreSQL 8.0+ for JDBC and other V3
> connection types.
>
> The rationale of this patch is to add fun
On Wed, 2005-05-11 at 22:15 -0400, Bruce Momjian wrote:
> > The patch was produced quickly to assist tuning efforts during
> > Scalability & Performance benchmarking of PostgreSQL 8.0 carried out at
> > Unisys Corporation's Mission Viejo engineering laboratory. The
> > development was sponsored by
Simon Riggs wrote:
> Following patch is a minor addition to postgres.c that allows the two
> existing statement logging techniques to work with V3 exec. This then
> allows statement logging with PostgreSQL 8.0+ for JDBC and other V3
> connection types.
Good.
> The rationale of this patch is to ad
17 matches
Mail list logo
