Re: Additional current timestamp values

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Brendan Jurd <direvus(at)gmail(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Additional current timestamp values
Date: 2006-03-21 01:58:22
Message-ID: 200603210158.k2L1wMY01170@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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?

I assume RULES should have the same statement_timestamp and I figured my
approach was the only one that would work.

> 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 suppose so.

> > 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.

Right.

--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc. http://www.sraoss.com

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-03-21 03:23:36 Re: [PATCHES] PL/pgSQL: #option select_into_1_row (was SELECT INTO
Previous Message Tom Lane 2006-03-21 00:04:40 Re: Additional current timestamp values

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-03-21 03:23:36 Re: [PATCHES] PL/pgSQL: #option select_into_1_row (was SELECT INTO
Previous Message Tom Lane 2006-03-21 00:04:40 Re: Additional current timestamp values