继续理解以下的数据库中的操作When a vertex execution fails for any reason the job manager is informed. If the vertex reported an error cleanly the process forwards it via the daemon before exiting; if the process crashes the daemon notifies the job manager; and if the daemon fails for any reason the job manager receives a heartbeat timeout. If the failure was due to a read error on an input channel (which is be reported cleanly) the default policy also marks the execution record that generated that version of the channel as failed and terminates its process if it is running. This will cause the vertex that created the failed input channel to be re-executed, and will lead in the end to the offending channel being re-created. Though a newly-failed execution record may have non-failed successor records, errors need not be propagated forwards: since vertices are deterministic two successors may safely compute using the outputs of different execution versions. Note however that under this policy an entire connected component of vertices connected by pipes or shared-memory FIFOs will fail as a unit since killing a running vertex will cause it to close its pipes, propagating errors in both directions along those edges. Any vertex whose execution record is set to failed is immediately considered for re-execution.

这段文字描述了在一个数据库中，顶点执行失败时的处理方式。如果顶点执行失败，作业管理器会被通知。如果顶点干净地报告了错误，进程会在退出前通过守护程序将错误信息转发给作业管理器。如果进程崩溃，守护程序会通知作业管理器。如果守护程序由于任何原因失败，作业管理器会接收到心跳超时。如果失败是由于输入通道上的读取错误（这将被干净地报告），则默认策略还会将生成该通道版本的执行记录标记为失败，并在其正在运行时终止其进程。这将导致创建失败输入通道的顶点被重新执行，并最终导致有问题的通道被重新创建。

尽管新失败的执行记录可能有未失败的后继记录，但错误不必向前传播：由于顶点是确定性的，两个后继者可以安全地使用不同执行版本的输出进行计算。但是，需要注意的是，在此策略下，由管道或共享内存FIFO连接的整个连接组件将作为一个单元失败，因为杀死运行的顶点将导致它关闭其管道，在这些边缘上向两个方向传播错误。任何执行记录被设置为失败的顶点都会立即被视为需要重新执行。

总之，这段文字描述了数据库中对顶点执行失败时的处理方式，包括错误通知、错误转发、重新执行等策略。同时也提到了顶点的确定性，以及管道或共享内存FIFO连接的组件将作为一个单元失败的情况。