On Feb 1, 2008 3:56 PM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /><div
class="gmail_quote"><blockquoteclass="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt
0pt0.8ex; padding-left: 1ex;"><div class="Ih2E3d">"Gurjeet Singh" <<a
href="mailto:singh.gurjeet@gmail.com">singh.gurjeet@gmail.com</a>>writes:<br /></div><div class="Ih2E3d">> The
situationseems pretty bad!!<br /><br /></div>I think at least part of your problem is not understanding that a
single<br/> transaction sees a frozen snapshot of pg_stat_activity.<br /><br /></blockquote></div><br />It does! I
assumedthat pg_stat_activity produced the transaction-independent snapshot of internal memory structures! Is that the
casewith pg_locks too!? I hope not.<br /><br />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
whenthe transaction started (which is how other (normal) relations behave). It's a bit confusing, and should be
documentedif this is the way it is intended to work; Something along the lines of : "In a transaction, this view will
repeatedlyshow the same results that were returned by it's first invocation in the transaction." in a less confusing
way:)<br /><br />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).<br clear="all" /><br />-- <br />
gurjeet[.singh]@EnterpriseDB.com<br/>singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com<br /><br />EnterpriseDB
<a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br /><br />17° 29' 34.37"N, 78° 30' 59.76"E
-Hyderabad<br /> 18° 32' 57.25"N, 73° 56' 25.42"E - Pune<br />37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco *<br
/><br/><a href="http://gurjeet.frihost.net">http://gurjeet.frihost.net</a><br /><br />Mail sent from my BlackLaptop
device