HP_SPOOL_BARRIER is a curiosity: a wait type introduced across various versions as part of a bug fix for parallel spool behaviour, then removed again in the very next cumulative update for each of those versions because the fix itself was flawed. Paul White documented the underlying bug and its circumstances in detail.
It exists in the wait catalogue as a fossil of that episode.
Is It a Problem?
If you can see it accumulating at all, the most useful conclusion is about your patch level: you are running one of the narrow band of builds that carried the flawed fix. The wait relates to barrier synchronisation around parallel spools, and on affected builds the associated behaviour was itself buggy.
On current builds it should simply not appear.
Common Causes
- Running one of the specific CU builds that introduced (and then dropped) the flawed parallel spool fix.
- Parallel plans with spools exercising the affected code path on those builds.
What To Do
- Check your build and patch forward; the successor CUs removed the problematic change.
- If a query misbehaves on an affected build and patching must wait, plan-shape workarounds that avoid the parallel spool (rewrites, hints) sidestep the path.
- Spend no effort on the wait itself; it is a build artefact.
How To See It
Rank it against everything else with Get-WaitStatistics; on patched systems, expect never to see it again.
Part of the SQL Server Wait Types Library.
Related deep dive: CXPACKET and CXCONSUMER Wait Types.
Leave a Reply