Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
