On Feb 1, 2008 3:56 PM, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
> The situation seems pretty bad!!
I think at least part of your problem is not understanding that a single
transaction sees a frozen snapshot of pg_stat_activity.
It does! I assumed that pg_stat_activity produced the transaction-independent snapshot of internal memory structures! Is that the case with pg_locks too!? I hope not.
BTW, we cannot say that the pg_stat_activity behaves in a consistent manner (transactions-wise). From what I could infer, this view's results are frozen when you first query the view, not when the transaction started (which is how other (normal) relations behave). It's a bit confusing, and should be documented if this is the way it is intended to work; Something along the lines of : "In a transaction, this view will repeatedly show the same results that were returned by it's first invocation in the transaction." in a less confusing way :)
So we are back to the original problem... Canceling a 'waiting' transaction does not revert the session's 'waiting' state back to 'false' (consistently reproducible).
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
EnterpriseDB
http://www.enterprisedb.com17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad
18° 32' 57.25"N, 73° 56' 25.42"E - Pune
37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco *
http://gurjeet.frihost.netMail sent from my BlackLaptop device
