"A Mergeout operation is already in progress on projection"

I see this error thousands of times each day in error_messages. Is there a tunable that should be reviewed? Or can this error message be ignored safely?

Vertica 6.1.1


  • Options
    Can it be ignored?  That depends on whether mergeout does manage to run the other times that it's kicking off internally.  To determine this, you could check tuple_mover_operations,or more simply, perhaps, verify that the ros_count in projection_storage is not outrageously high. The mergeout process is responsible for collapsing multiple files into fewer/larger files on disk. If that's not happening, you're going to be knocking on ROS pushback's door very soon, and that's not a doorstep you want to be on.

    The bigger question is why it seems to be happening so often. I am aware of (valid, and benign) scenarios in which moveout might provoke such an error, but not mergeout. So, it might be worth having our support teams dig a bit deeper into the why of this problem.

    Are you doing something out of the ordinary on such a consistent basis that would be provoking mergeout to execute more often than it needs to?

  • Options
    I am also seeing this error message on version vertica-6.1.3-10 in cases where there are more mergeouts threads ( TM maxconcurency  = 4 , plannedconcurrency = 3) and some table is loaded frequently. It appears that mergeout threads are not avoiding ROS containers that are already involved in a mergeout. Is this by design of the product or something else is broken ? 
    The mergeouts are completing correctly and the overall ROS count is not increasing alarmingly. 
    The reason for having multiple mergeouts is the aggressive ETL process that might hold a single mergeout thread busy for too long . 

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file