Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> 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.

Well, I don't think TransactionIdIsCurrentTransactionId() itself is to
blame --- the loop over childXids is about as tight as such a loop could
possibly be (two indirect fetches and a comparison per iteration).
Even with 4.6M child Xids it could hardly take a second on any modern
machine.  I'm not inclined to add a CHECK_FOR_INTERRUPTS there.  The
problem should instead be blamed on something further down the call
stack ... did you save the full stack by any chance?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to