Re: Additional current timestamp values

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Tom Lane wrote:
> >> The patch as given strikes me as pretty broken --- it does not advance
> >> statement_timestamp when I would expect (AFAICS it only sets it during
> >> transaction start).
>
> > Uh, it does advance:
>
> But not once per statement --- in reality, you get a fairly arbitrary
> behavior that will advance in some cases and not others when dealing
> with a multi-statement querystring. Your example showing that it fails
> to advance in a psql -c string shows this ... don't you think most
> people would call that a bug?
>
> If it's "statement" timestamp then I think it ought to advance once per
> SQL statement, which this isn't doing. (As I already said, though, that
> isn't the behavior I really want. My point is just that the code's
> behavior is an extremely strange, nonintuitive definition of the word
> "statement".)
>
> > I have always been confused if
> > statement_timeout times queries inside server-side functions, for
> > example. I don't think it should.
>
> That's exactly my point; I agree that we don't want it doing that,
> but that being the case, "statement" isn't a great name for the units
> that we are actually processing. We're really wanting to do these
> things once per client command, or maybe per client query would be a
> better name.

I have updated my patch based on community comments. One cleanup is
that I now set statement_timestamp(), and then base
transaction_timestamp() (aka now()) on the statement_timestamp of BEGIN,
which is a much cleaner API.

As far as how often statement_timestamp() is called, when a "Q" query
arrives, it calls exec_simple_query(), which calls start_xact_command()
before it parses anything, setting the transaction start. It is called
inside the per-command loop, but it does nothing unless
finish_xact_command() was called to finish a transaction.

(Is there some double-processing here for BEGIN because it will re-run
the initialization stuff?)

I also documented how statement_timestamp behaves when multiple
statements are in the same query string, and when called from functions.

One side-affect of tracking transaction_timestamp based on
statement_timestamp() is if multiple statements are sent in a single
query string, and multiple transactions are used, statement_timestamp
will be advanced so transaction_timestamp() can vary. Again, not ideal,
but probably the cleanest we are going to be able to do. If we decided
to just have statement_timestamp be the arrival of the string always, we
are going to incur additional gettimeofday() calls and the code is going
to be more complex.

FYI, this is exactly how statement_timeout behaves, and no one has
complained about it.

The only other approach would be to put the statement_timestamp()
setting call in exec_simple_query(), and in all the protocol-level
functions, and fastpath. You then also need to do a separate call for
transaction_timestamp() because you want that to advance if multiple
transactions are in the same query string.

If we want to take that approach, should statement_timeout code also be
moved around?

See my other post about the use of the term "statement". I don't think
most people think about sending multiple statements, so if we document
its behavior, that is good enough.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

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