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 Schlossnagle
// CTO --
// OmniTI Computer Consulting, Inc. --

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to