Hi,

Thanks for the response. Confirmed previously that the merge agent is locking tables that have a high maxversion_at_cleanup - one of the two tables that I mentioned - and I've tried leaving the blocking process run for 24+ hours before killing it to free the lock. It's always the merge agent with the lock that is blocking other processes, and at the time the blocking merge agent's last message is that it's waiting for a response from the query SP_MSUPLINEAGEVERSION(?,?,?). Other resources I've found point to a loop in that SP that is somehow tied to maxversion_at_cleanup (such as this old one on MSDN - https://social.msdn.microsoft.com/Forums/sqlserver/en-US/86c50afd-48db-46a0-b94c-b804453c992a/maxversionatcleanup?forum=sqlreplication). Hence my more specific question.

Any ideas about the maxversion_at_cleanup column specifically and how it's connected to SP_MSUPLINEAGEVERSION? Why an article may have a value in the 2+ billion? How this column behaves and is maintained in merge replication? It's an int that is almost at its maximum value, does it ever reset on its own, or is there maintenance that can cause a reset without dropping/adding back the article?

Of note that I never thought of in my OP: These two articles are join filters to parent articles (unique join keys). The parent/child articles are both partition_options 1 for overlapping with disallow out of partition changes.