bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > Dave Cramer wrote:
> > >> Bind also has a statement name, as well as a portal name ?
> > >>
> > >> Ideally I'd like to see the parameters which were bound and the
> > >> types, but I suspect I'm reaching here.
> >
> > > Right, but do we want to repeat the statement for every bind case?
> >
> > My upthread proposal was to print the statement and portal names
> > at bind time. The current printout is very clearly inadequate.
>
> Sure, I can do that.
>
> Did you like my idea of?
>
> statement: <protocol execute> ...
>
> You didn't reply. I want to keep the "statement:" prefix for scripts
> that process our log files, and because it is output by log_statement,
> which controls protocol output as well.

I have applied this patch to output the statemented referenced by BIND.
I also changed the "[protocol]" string to "<protocol>" for clarity. I
am ready to pull PREPARE|BIND|EXECUTED into the "protocol" bracket too
if someone says that is a good idea.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Bruce,

Doesn't it make more sense to use the statement name ?

If I prepare S_3 as "select * from foo"

then the bind log is going to show me "select * from foo" not S_3

I think in the case of named statements I'd prefer "S_3" however as I
think about this in the case of unnamed statements I'd prefer the
"select * from foo"

Comments ?

Dave
On 4-Aug-06, at 2:56 PM, Bruce Momjian wrote:

> bruce wrote:
>> Tom Lane wrote:
>>> Bruce Momjian <bruce@momjian.us> writes:
>>>> Dave Cramer wrote:
>>>>> Bind also has a statement name, as well as a portal name ?
>>>>>
>>>>> Ideally I'd like to see the parameters which were bound and the
>>>>> types, but I suspect I'm reaching here.
>>>
>>>> Right, but do we want to repeat the statement for every bind case?
>>>
>>> My upthread proposal was to print the statement and portal names
>>> at bind time. The current printout is very clearly inadequate.
>>
>> Sure, I can do that.
>>
>> Did you like my idea of?
>>
>> statement: <protocol execute> ...
>>
>> You didn't reply. I want to keep the "statement:" prefix for scripts
>> that process our log files, and because it is output by
>> log_statement,
>> which controls protocol output as well.
>
> I have applied this patch to output the statemented referenced by
> BIND.
> I also changed the "[protocol]" string to "<protocol>" for clarity. I
> am ready to pull PREPARE|BIND|EXECUTED into the "protocol" bracket too
> if someone says that is a good idea.
>
> --
> Bruce Momjian bruce@momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
> Index: src/backend/tcop/postgres.c
> ================================================== =================
> RCS file: /cvsroot/pgsql/src/backend/tcop/postgres.c,v
> retrieving revision 1.493
> diff -c -c -r1.493 postgres.c
> *** src/backend/tcop/postgres.c 29 Jul 2006 03:02:56 -0000 1.493
> --- src/backend/tcop/postgres.c 4 Aug 2006 18:50:59 -0000
> ***************
> *** 1146,1153 ****
>
> if (log_statement == LOGSTMT_ALL)
> ereport(LOG,
> ! (errmsg("statement: [protocol] PREPARE %s AS %s",
> ! (*stmt_name != '\0') ? stmt_name : "<unnamed>",
> query_string)));
>
> /*
> --- 1146,1153 ----
>
> if (log_statement == LOGSTMT_ALL)
> ereport(LOG,
> ! (errmsg("statement: <protocol> PREPARE %s AS %s",
> ! *stmt_name ? stmt_name : "<unnamed>",
> query_string)));
>
> /*
> ***************
> *** 1452,1458 ****
> /* We need to output the parameter values someday */
> if (log_statement == LOGSTMT_ALL)
> ereport(LOG,
> ! (errmsg("statement: [protocol] <BIND> %s", portal_name)));
>
> /*
> * Fetch parameters, if any, and store in the portal's memory
> context.
> --- 1452,1460 ----
> /* We need to output the parameter values someday */
> if (log_statement == LOGSTMT_ALL)
> ereport(LOG,
> ! (errmsg("statement: <protocol> <BIND> %s [PREPARE: %s]",
> ! *portal_name ? portal_name : "<unnamed>",
> ! portal->sourceText ? portal->sourceText : "")));
>
> /*
> * Fetch parameters, if any, and store in the portal's memory
> context.
> ***************
> *** 1718,1726 ****
> if (log_statement == LOGSTMT_ALL)
> /* We have the portal, so output the source query. */
> ereport(LOG,
> ! (errmsg("statement: [protocol] %sEXECUTE %s [PREPARE: %s]",
> execute_is_fetch ? "FETCH from " : "",
> ! (*portal_name) ? portal_name : "<unnamed>",
> portal->sourceText ? portal->sourceText : "")));
>
> BeginCommand(portal->commandTag, dest);
> --- 1720,1728 ----
> if (log_statement == LOGSTMT_ALL)
> /* We have the portal, so output the source query. */
> ereport(LOG,
> ! (errmsg("statement: <protocol> %sEXECUTE %s [PREPARE: %s]",
> execute_is_fetch ? "FETCH from " : "",
> ! *portal_name ? portal_name : "<unnamed>",
> portal->sourceText ? portal->sourceText : "")));
>
> BeginCommand(portal->commandTag, dest);
> ***************
> *** 1826,1836 ****
> secs, msecs)));
> else
> ereport(LOG,
> ! (errmsg("duration: %ld.%03d ms statement: [protocol] %
> sEXECUTE %s [PREPARE: %s]",
> secs, msecs,
> execute_is_fetch ? "FETCH from " : "",
> ! (*portal_name) ? portal_name : "<unnamed>",
> ! portal->sourceText ? portal->sourceText : "")));
> }
> }
>
> --- 1828,1838 ----
> secs, msecs)));
> else
> ereport(LOG,
> ! (errmsg("duration: %ld.%03d ms statement: <protocol> %
> sEXECUTE %s [PREPARE: %s]",
> secs, msecs,
> execute_is_fetch ? "FETCH from " : "",
> ! *portal_name ? portal_name : "<unnamed>",
> ! portal->sourceText ? portal->sourceText : "")));
> }
> }
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Dave Cramer wrote:
> Bruce,
>
> Doesn't it make more sense to use the statement name ?
>
> If I prepare S_3 as "select * from foo"
>
> then the bind log is going to show me "select * from foo" not S_3
>
> I think in the case of named statements I'd prefer "S_3" however as I
> think about this in the case of unnamed statements I'd prefer the
> "select * from foo"

The bind shows:

(errmsg("statement: <protocol> <BIND> %s [PREPARE: %s]",

The first %s is the statement name, and the second %s is the query.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian <bruce@momjian.us> writes:
> ! (errmsg("statement: [protocol] <BIND> %s", portal_name)));

> --- 1452,1460 ----
> ! (errmsg("statement: <protocol> <BIND> %s [PREPARE: %s]",
> ! *portal_name ? portal_name : "<unnamed>",
> ! portal->sourceText ? portal->sourceText : "")));

This is getting less readable not more so; and you still haven't got the
prepared statement's name in there, let alone any place to put the
parameter values.

Perhaps we should give up on the idea that this can all fit on one log
line? Maybe

LOG: parse: <statement-name>
DETAIL: statement: <source-text>

LOG: bind: <portal-name> to <statement-name>
DETAIL: statement: <source-text>
parameter 1: <parameter value>
parameter 2: <parameter value>
...

LOG: execute: <portal-name>
DETAIL: statement: <source-text>

The $64 question here is whether we want to repeat the source-text
in all three messages (parse, bind, execute) or try to reduce the
verbosity.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > ! (errmsg("statement: [protocol] <BIND> %s", portal_name)));
>
> > --- 1452,1460 ----
> > ! (errmsg("statement: <protocol> <BIND> %s [PREPARE: %s]",
> > ! *portal_name ? portal_name : "<unnamed>",
> > ! portal->sourceText ? portal->sourceText : "")));
>
> This is getting less readable not more so; and you still haven't got the
> prepared statement's name in there, let alone any place to put the
> parameter values.

I thought the portal name was the statement name. Seems I was wrong.

> Perhaps we should give up on the idea that this can all fit on one log
> line? Maybe
>
> LOG: parse: <statement-name>
> DETAIL: statement: <source-text>
>
> LOG: bind: <portal-name> to <statement-name>
> DETAIL: statement: <source-text>
> parameter 1: <parameter value>
> parameter 2: <parameter value>
> ...
>
> LOG: execute: <portal-name>
> DETAIL: statement: <source-text>
>
> The $64 question here is whether we want to repeat the source-text
> in all three messages (parse, bind, execute) or try to reduce the
> verbosity.

We don't print DETAIL in the logs, do we?

Does anyone have C code that uses these features so I can test?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian <bruce@momjian.us> writes:
> The bind shows:
> (errmsg("statement: <protocol> <BIND> %s [PREPARE: %s]",
> The first %s is the statement name, and the second %s is the query.

No, it's the portal name. There's a difference.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian <bruce@momjian.us> writes:
> We don't print DETAIL in the logs, do we?

Yes, we do, unless you've set log_error_verbosity to less than the
default.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend