当SUMA内核块接收到 SUB_STOP_REQ信号时，它会执行信号然后回复SUB_STOP_CONF。（此响应被中继回 API 后，API 将打开以发送更多SUB_STOP_REQ信号。）发送 后 SUB_STOP_CONF，如果没有订阅者，SUMA 将删除订阅，这涉及向 发送多 DROP_TRIG_IMPL_REQ条消息 DBTUP。LocalProxy 最多可以并行处理其中的 21 个请求；多于此的都在短时间队列中排队。当 a 的执行 DROP_TRIG_IMPL_REQ被延迟时，队列有可能变得过载，导致数据节点关闭并出现Error in short time queue。

SUB_STOP_REQ如果 DBTUP已经 DROP_TRIG_IMPL_REQ满负荷处理信号，而不是排队信号， 则通过延迟信号的执行来解决此问题 DROP_TRIG_IMPL_REQ。（漏洞 #26574003）

拥有大量延迟触发器有时会导致作业缓冲区耗尽。发生这种情况的原因可能是单个触发器可以执行多个操作——例如，外键父触发器可以对多个匹配的子表行执行操作——并且对基表的行操作可以执行多个触发器。在这种情况下，行操作是分批执行的。当延迟执行许多触发器时——意味着所有延迟的触发器都在预提交时执行——由此产生的大量触发器操作的并发执行可能会导致数据节点作业缓冲区或发送缓冲区耗尽，从而导致节点故障.

此问题已通过限制并发触发器操作的数量以及每个事务未完成的触发器触发请求的数量得到解决。

对于即时触发器，限制并发触发器操作可能会增加等待执行的触发器数量，耗尽触发器记录池并导致错误Too many concurrently fired triggers (increase MaxNoOfFiredTriggers . This can be avoided by increasing MaxNoOfFiredTriggers, reducing the user transaction批量大小，或两者兼而有之。（缺陷 #22529864）

参考资料：另请参阅：Bug #18229003、Bug #27310330。