> On Apr 8, 2015, at 3:43 PM, Vasudevan, Ramya <ramya.vasude...@classmates.com> > wrote: > > Thank You John. > > > the state_change to idle-in-transaction took place about 0.0001 seconds > > later (so the insert took all of a millisecond). > Yes, the DML “finished” but stayed uncommitted. > > > What date/time was it when you did that select from pg_stat_activity ? > > thats how long this transaction has been pending, which if its more than a > > few seconds to at most a minute, is almost certainly a 'very bad thing' > > unless the transaction is actively crunching data. > 2015-04-07 14:25 – ~17 hours after the DML ran. > Agreed, it was bad. There was nothing happening with this transaction since > 2015-04-06 21:16:26. It was just sitting there. > > > if you're using a client such as JDBC which autowraps queries in > > transactions by default, you need to invoke COMMIT's when you're done doing > > that unit of work. > This is what I am trying to confirm from the application side. It will help > the dev team if they have the value for bind variables apparently. > > Any idea on how to get the values for bind variables for a transaction like > this? > > Thank You > Ramya
I don’t recall seeing what stack this application is using, but it’s probably easier for the dev to start collecting the “bind variables”. (A simple config in hibernate, for instance) If you’re logging sql at the server, then you have the values somewhere in the logs, else “it doesn’t matter, it is in the past”
