Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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
Bruce Momjian pgman@candle.pha.pa.us 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?
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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 ---
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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,
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 statement
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 because even
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 Is 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
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
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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 Unisys
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 add
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 functionality without modifying
16 matches
Mail list logo
