Bruce Momjian wrote:
Simon's page is in the patches queue. What would you like changed,
exactly?
I'm not going to have time to comment on this any time soon, sorry :( ..
I guess I will try to look at it for 8.2.
-O
---(end of broadcast)---
TIP
Oliver Jowett wrote:
Bruce Momjian wrote:
Well, from the application writer perspective, you are right it doesn't
make sense,
This is exactly what the end user is going to say.
but this is only because jdbc is using prepare internally.
Isn't this mostly irrelevant to the result
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Oliver Jowett wrote:
Simon Riggs wrote:
Are we sure there is just 3 cases?
I haven't exhaustively checked, but I think those are the main cases.
Even if case (3) is not that common, I still want to know it is
occurring, to see what effect or overhead it has.
I don't want it to be
Bruce Momjian wrote:
We don't have a log_statement = verbose mode.
Please see my earlier email where I suggested adding one if you really
wanted all this protocol-level detail logged.
-O
---(end of broadcast)---
TIP 1: if posting/reading
Bruce Momjian wrote:
I think it is more verbose because no FETCH is logged in this type of
prepare/execute. The goal, I think, is for these type of queries to
look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
I do not understand why this is a useful thing to do as part
Oliver Jowett wrote:
Bruce Momjian wrote:
We don't have a log_statement = verbose mode.
Please see my earlier email where I suggested adding one if you really
wanted all this protocol-level detail logged.
We can't add that in feature freeze/beta, at least.
--
Bruce Momjian
Oliver Jowett wrote:
Bruce Momjian wrote:
I think it is more verbose because no FETCH is logged in this type of
prepare/execute. The goal, I think, is for these type of queries to
look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
I do not understand why this is
Bruce Momjian wrote:
Well, from the application writer perspective, you are right it doesn't
make sense,
This is exactly what the end user is going to say.
but this is only because jdbc is using prepare internally.
Isn't this mostly irrelevant to the result we want to see? It's a detail
of
Simon Riggs wrote:
Are we sure there is just 3 cases?
I haven't exhaustively checked, but I think those are the main cases.
Even if case (3) is not that common, I still want to know it is
occurring, to see what effect or overhead it has.
I don't want it to be more verbose than the other
On Thu, 2005-09-08 at 13:14 +1200, Oliver Jowett wrote:
Simon Riggs wrote:
Oliver, would it be possible to show a simplified call sequence and what
you would like to see logged for each call?
These are good: Maybe it should even be in the docs for the driver?
It would be good if it could be
Oh, I didn't realize a FETCH would show up as an EXECUTE. That is wrong
and should be fixed because a user-level FETCH shows up as a fetch, not
as the original query.
---
Simon Riggs wrote:
Oliver Jowett wrote:
On Thu, 2005-09-08 at 13:14 +1200, Oliver Jowett wrote:
Simon Riggs wrote:
On Tue, 2005-09-06 at 07:47 +, Oliver Jowett wrote:
Simon Riggs wrote:
Looking more closely, I don't think either is correct. Both can be reset
according to rewind operations - see DoPortalRewind().
We'd need
On Tue, 2005-09-06 at 07:47 +, Oliver Jowett wrote:
Simon Riggs wrote:
Looking more closely, I don't think either is correct. Both can be reset
according to rewind operations - see DoPortalRewind().
We'd need to add another bool onto the Portal status data structure.
AFAIK this
On Mon, 2005-09-05 at 15:38 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
+ /*
+ * If we re-issue an Execute protocol request against an existing
+ * portal, then we are only fetching more rows rather than
+ * completely re-executing the query from the
Simon Riggs wrote:
Looking more closely, I don't think either is correct. Both can be reset
according to rewind operations - see DoPortalRewind().
We'd need to add another bool onto the Portal status data structure.
AFAIK this is only an issue with SCROLLABLE cursors, which v3 portals
Oliver Jowett wrote:
8.1-beta1 produces some odd results with statement logging enabled when
the extended query protocol is used (e.g. when using the JDBC driver).
Repeatedly running a simple query with log_statement = 'all' produces this:
...
Secondly, running a query that uses
Simon Riggs [EMAIL PROTECTED] writes:
+ /*
+ * If we re-issue an Execute protocol request against an existing
+ * portal, then we are only fetching more rows rather than
+ * completely re-executing the query from the start
+ */
+ if (!portal-atEnd)
+
Simon Riggs wrote:
Subsequent calls to the same portal are described as FETCHes rather than
as EXECUTEs. The portal name is still given and number of rows is
provided also.
I wonder if it might be better to only log the first Execute.. It's not
immediately clear to me that it's useful to see
I have applied the following patch to output unnamed for unnamed
prepared statements. As far as your other issues, how would you want
server-side statements to be logged? statement: is a log label for a
statement. What else should we use?
8.1-beta1 produces some odd results with statement logging enabled when
the extended query protocol is used (e.g. when using the JDBC driver).
Repeatedly running a simple query with log_statement = 'all' produces this:
LOG: statement: PREPARE AS SELECT 'dummy statement'
LOG: statement: BIND
21 matches
Mail list logo
