Comments

The lock timeout is not an error. It's likely expected behavior. You'd have to look at the locks table to see why that other transaction is holding a lock. You can't simply look at the transactions current statement, since locks are held until commit or rollback (and transactions can have many statements). Although looking out here it looks like the S lock was aquired by dbadmin user on the same table "kafka_lock" where it timed out (depending on LockTimeout parameter set in your cluster) waiting for it to release it to perform other operations which required exclusive lock.

As expected, I see that the kafka shceduler form node1 acquire lock, for write datas from kafka into vertica. But I wonder, why the node2 kafka scheduler, don't go to the stand-by mode for hand-off the node1, in case it fail? Whe the node2, instead of be in stand-by mode, try do: