On Sun, 2005-04-10 at 17:54 +1200, Oliver Jowett wrote:
Simon Riggs wrote:
I've got a patch to submit that logs the EXEC phase, so you get just the
SQL, not the parameters. [...]
Just testing against cvstip and wrapping now...
I assume this replaces the current logging on Parse to avoid
Simon Riggs wrote:
I assume this replaces the current logging on Parse to avoid duplicate
logging?
Well, I'm open to discussion, but that isn't what the patch does.
I guess I'll wait for your patch and take a look rather than try to
guess about what it does, then.
My thinking was to add
Oliver Jowett [EMAIL PROTECTED] writes:
Simon Riggs wrote:
OK, thats what I hoped you'd say. With a prepared query all of the
statements execute the same plan, so you don't need to know the exact
parameters.
This isn't true in 8.0 if you are using the unnamed statement (as the
JDBC
Simon Riggs wrote:
I've got a patch to submit that logs the EXEC phase, so you get just the
SQL, not the parameters. [...]
I assume this replaces the current logging on Parse to avoid duplicate
logging?
What happens on syntax errors? It's useful to log the statement that
failed, but you will
On Fri, 2005-04-08 at 00:51 +0200, Palle Girgensohn wrote:
--On torsdag, april 07, 2005 23.31.52 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
On Wed, 2005-04-06 at 15:01 +0200, Palle Girgensohn wrote:
I really need to know the *real* arguments...
Why do you need to log the arguments as
Simon Riggs wrote:
OK, thats what I hoped you'd say. With a prepared query all of the
statements execute the same plan, so you don't need to know the exact
parameters.
This isn't true in 8.0 if you are using the unnamed statement (as the
JDBC driver does in some cases): the plan chosen
Oliver Jowett [EMAIL PROTECTED] writes:
Simon Riggs wrote:
OK, thats what I hoped you'd say. With a prepared query all of the
statements execute the same plan, so you don't need to know the exact
parameters.
This isn't true in 8.0 if you are using the unnamed statement (as the
JDBC driver
--On torsdag, april 07, 2005 14.34.22 +1200 Oliver Jowett
[EMAIL PROTECTED] wrote:
Greg Stark wrote:
Palle Girgensohn [EMAIL PROTECTED] writes:
When setting log_statement = all, and using JDBC PreparedStatements, I
get $n in the log where the real arguments used to be in previous
versions of
On Wed, 2005-04-06 at 15:01 +0200, Palle Girgensohn wrote:
I really need to know the *real* arguments...
Why do you need to log the arguments as well?
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through
--On torsdag, april 07, 2005 23.31.52 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
On Wed, 2005-04-06 at 15:01 +0200, Palle Girgensohn wrote:
I really need to know the *real* arguments...
Why do you need to log the arguments as well?
Debugging purposes. If I fealize there are queries hogging the
Hi!
When setting log_statement = all, and using JDBC PreparedStatements, I get
$n in the log where the real arguments used to be in previous versions of
postgresql:
postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data
(this_group_id, item_text, link_path) VALUES ($1, $2, $3)
I
Palle Girgensohn [EMAIL PROTECTED] writes:
When setting log_statement = all, and using JDBC PreparedStatements, I get $n
in the log where the real arguments used to be in previous versions of
postgresql:
postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data
(this_group_id,
postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data (this_group_id,
item_text, link_path) VALUES ($1, $2, $3)
I really need to know the *real* arguments... How can I get them? Is it a bug?
The bug was that prepared statements didn't work properly in the past. That is
the statement
Christopher Kings-Lynne wrote:
I think he has a really excellent point. It should log the parameters
as well.
neilc=# prepare foo(int, int) as select $1 + $2;
PREPARE
neilc=# execute foo(5, 10);
...
neilc=# execute foo(15, 20);
...
% tail /usr/local/pgsql/postmaster.log
LOG: statement: prepare
At 2005-04-07 12:14:19 +1000, [EMAIL PROTECTED] wrote:
% tail /usr/local/pgsql/postmaster.log
LOG: statement: prepare foo(int, int) as select $1 + $2;
LOG: statement: execute foo(5, 10);
LOG: statement: execute foo(15, 20);
If you send a v3 protocol execute message instead of an SQL
On Thu, Apr 07, 2005 at 12:14:19PM +1000, Neil Conway wrote:
Christopher Kings-Lynne wrote:
I think he has a really excellent point. It should log the parameters
as well.
neilc=# prepare foo(int, int) as select $1 + $2;
PREPARE
neilc=# execute foo(5, 10);
...
neilc=# execute foo(15,
Neil Conway wrote:
Christopher Kings-Lynne wrote:
I think he has a really excellent point. It should log the parameters
as well.
neilc=# prepare foo(int, int) as select $1 + $2;
PREPARE
neilc=# execute foo(5, 10);
...
neilc=# execute foo(15, 20);
...
% tail
Oliver Jowett wrote:
Query-level EXECUTE is logged, but Bind/Execute via the V3 extended
query protocol (which is what the JDBC driver does) isn't.
Ah, I see. Yes, that certainly needs to be fixed.
-Neil
---(end of broadcast)---
TIP 8: explain
Greg Stark wrote:
Palle Girgensohn [EMAIL PROTECTED] writes:
When setting log_statement = all, and using JDBC PreparedStatements, I get $n
in the log where the real arguments used to be in previous versions of
postgresql:
You might want to look into JDBC options to disable use of prepared
Oliver Jowett [EMAIL PROTECTED] writes:
In fact, the logging for the extended query protocol really sucks:
Without doubt. Someone has to sit down and think about exactly what
we should log, where when and how ... proposals welcome ...
regards, tom lane
20 matches
Mail list logo
