Can somebody tell me why I've got two locks (X and T) on the same transaction using update operator?
Greetings experts. Can somebody tell me why I've got two locks (X and T) on the same transaction using update operator?
The 1st one is X-lock (exclusive due to update operator)
The 2nd is T (tuple mover mergout)
Both lock on the same transaction. Transaction hanging in lock condition infinitely.
How it happens and how can we avoid situations like this?
0
Comments
Hi
As "X" lock is always needed for delete or update (Insert + delete) operations.
The two main tasks that a Tuple Mover performs, are Moveout and Mergeout. A Mergeout is the process of consolidating ROS containers and purging deleted records. A Moveout operation moves data from memory (WOS) to disk (ROS).
The "T" lock is a Tuple Mover lock used by the Tuple Mover (and also used for COPY into pre-join projections). When Tuple Mover performs the Mergeout, it will acquire a T-Lock on the table(s) it is working on.
Just for your information the "T" lock and "X" lock conflict (incompatible) with one another. If there is a "T" lock on a table, an "X" lock cannot be granted on it, and vice versa. This is called lock conflict, and is the correct expected behaviour.Can you kindly let us know what error you have received if any?
Regards
Rahul Choudhary
Hi
I read documenation and I know exacly what every type of lock means. And I know about ROS and WOS and TM and so on.
The point is: transaction consists of update operator with join inside and I've got X on updating table and T on joining table. That is why transaction hangs. Infinitely. No any errors.
How I can avvoid it instead of oprimize update operator, kill TP or pray?
I remember that I didnt put the right answer here
Th issue was because of TP pool had higher priority than general pool. And yes, It was dead lock.