In production today (8.1.4), I ran into a backend process that
wouldn't cancel right away -- minutes went by.
It was in
[0] TransactionIdIsCurrentTransactionId
[1] HeapTupleSatisfiesSnapshot
...
But the interesting thing is that there were 4.6 million elements in
the s->childXids list. Which is why it took so damn long. I can't
quite figure out how I induced this state. It is an OLAP server with
about 10-20 connection that run "long" queries (from 5 seconds to 24
hours).
If this is a common possible state, it seems that perhaps a hash of
the childXids would be more appropriate. Does the order of the
childXids chained off the current transaction state matter? Most of
the placed I could find that reference it seem to just attempt to
find an Xid in there. O(1) sounds a lot better than O(n) :-D
Best regards,
Theo
// Theo Schlossnagle
// CTO -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
