Re: statement logging / extended query protocol issues

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: statement logging / extended query protocol issues
Date: 2005-09-19 17:50:22
Message-ID: 200509191750.j8JHoML25074@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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 we want to see? It's a detail
> of how the interface layer chooses to execute its queries, and 90% of
> the time the end user is not going to know or care about it.

Right, but have no way to know if the user is using an interface that
hides prepares from them, or they are using prepares visibly in their
applications. For this reason, we should just display whatever the
backend is doing. If all interfaces used prepares invisibly like jdbc,
we would be right to suppress the log information.

> > If you were to have written it in libpq, it would make sense, I think,
> > and internally, this is what is happening. We can't assume only
> > interface libraries like jdbc are using this feature.
>
> Wait, so is the extended query protocol the poor cousin of "what libpq
> does", or what? You can do Parse/Bind using libpq, can't you?

Sure.

> The *meaning* of the Parse/Bind/Execute sequence is quite clear
> regardless of what interface library is used. I still think that logging
> just the queries that were actually executed, once per execution, is the
> sensible thing to do here. I can't see a sequence of protocol messages
> that would produce a strange result if we used the rules I suggested --
> do you have an example where it breaks?

I have no idea.

> > As far as I understand things, the protocol-level prepare/execute is
> > identical to the SQL-level prepare/execute, except that there is no need
> > to parse the execute, so it should log like the SQL-level statements, if
> > possible.
>
> You can Parse any SQL statement, but you can't PREPARE any SQL
> statement. So, no, they're not equivalent. That's one aspect of what I
> meant about generating synthetic statements that weren't syntactially
> correct (the strange FETCH syntax with ROWS/MAXROWS that Simon was
> suggesting is another case).

I am hesitant to add another log syntax to be used just for
protocol-level prepare. I think it adds complexity with little benefit,
particularly for people reading those logs with automated tools.

Simon's page is in the patches queue. What would you like changed,
exactly?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Guillaume LELARGE 2005-09-19 18:24:32 Re: Start translating
Previous Message Bruce Momjian 2005-09-19 17:21:12 Re: statement_timeout logging

Browse pgsql-patches by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-09-19 17:51:07 [PATCH] Add support for IS NULL to btree indexes
Previous Message Jim C. Nasby 2005-09-19 15:05:16 Re: Per-table freeze limit proposal