On Wed, Sep 26, 2018 at 10:55 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2018-Sep-26, Tom Lane wrote: > > > 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. > > While that's true, I think it's also highly hypothetical. > > What could be the use for the transaction timestamp? I think one of the > most important uses (at least in pg_stat_activity) is to verify that > transactions are not taking excessively long time to complete;
+1 I think the existing behavior is broken, and extremely so. Transaction timestamp has a very clear definition to me. I'm in planning to move a lot of code into stored procedures from bash, and upon doing so it's going to trip all kinds of nagios alarms that are looking at the longest running transaction. merlin
