Re: Additional current timestamp values
От | Tom Lane |
---|---|
Тема | Re: Additional current timestamp values |
Дата | |
Msg-id | 9191.1142899480@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Additional current timestamp values (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Additional current timestamp values
Re: Additional current timestamp values |
Список | pgsql-patches |
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? 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. regards, tom lane
В списке pgsql-patches по дате отправления: