"A Mergeout operation is already in progress on projection"

Jack_Kidwell

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

Curtis_1

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?

colin_loghin

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 .