On Wed, Sep 26, 2018 at 10:55 AM Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
>
> On 2018-Sep-26, Tom Lane wrote:
>
> > Alvaro Herrera <alvherre@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
