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)---
TI
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
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
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
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
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
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 thro
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 wa
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.
---
Si
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 c
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 coul
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().
>
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:
> > > 8.
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.
>
>
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
aren't
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
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 se
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)
> +
> 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 use
I have applied the following patch to output "" 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:
LOG: s
21 matches
Mail list logo
