Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > On 2018-Sep-26, Tom Lane wrote: >> I agree that it would be surprising for transaction timestamp to be newer >> than statement timestamp. So for now at least, I'd be satisfied with >> documenting the behavior.
> Really? I thought it was practically obvious that for transaction- > controlling procedures, the transaction timestamp would not necessarily > be aligned with the statement timestamp. The surprise would come > together with the usage of the new feature, so existing users would not > be surprised in any way. Nope. That's the same poor reasoning we've fallen into in some other cases, of assuming that "the user" is a point source of knowledge. But DBMSes tend to interact with lots of different code. If some part of application A starts using intraprocedure transactions, and then application B breaks because it wasn't expecting to see xact_start later than query_start in pg_stat_activity, you've still got a problem. I'm also a bit hesitant to invent new semantics here based on the assumption that we've got only one, nonoverlapping, top-level transaction at a time. It's not terribly hard to imagine suspend-and-resume- transaction features coming down the pike at some point. What will we do then? We'll already have a definitional issue for xact_start, but it'll get worse the more different kinds of xact_start we have. regards, tom lane