Спасибо, хороший поинт. В моём случае при claim я обновляю только неключевые поля (is_occupied/worker_id/...), поэтому FOR NO KEY UPDATE действительно семантически корректнее и потенциально уменьшает лишние конфликты (в т.ч. с FOR KEY SHARE/FK). Поменяю в примере на FOR NO KEY UPDATE SKIP LOCKED
Классная идея, спасибо — да, pg_backend_pid() + pg_stat_activity могут заменить heartbeat, если воркер держит долгоживущий коннект и есть доступ к pg_stat_activity
Если же воркер использует пул и разные задачи идут через разные коннекты, то pg_backend_pid() будет меняться, и PID перестаёт быть надёжной “идентичностью воркера”
И ещё момент: “процесс/соединение живо” ≠ “воркер делает progress”. Он может зависнуть внутри (deadlock в коде, зависший внешний вызов, stuck event loop) — в этом случае backend в pg_stat_activity всё ещё может быть виден. Heartbeat решает именно это: “если давно не пинговал — считаем мёртвым”, даже если TCP/процесс жив.
Спасибо, хороший поинт. В моём случае при claim я обновляю только неключевые поля (
is_occupied/worker_id/...), поэтомуFOR NO KEY UPDATEдействительно семантически корректнее и потенциально уменьшает лишние конфликты (в т.ч. сFOR KEY SHARE/FK). Поменяю в примере наFOR NO KEY UPDATE SKIP LOCKEDКлассная идея, спасибо — да,
pg_backend_pid()+pg_stat_activityмогут заменить heartbeat, если воркер держит долгоживущий коннект и есть доступ кpg_stat_activityЕсли же воркер использует пул и разные задачи идут через разные коннекты, то
pg_backend_pid()будет меняться, и PID перестаёт быть надёжной “идентичностью воркера”И ещё момент: “процесс/соединение живо” ≠ “воркер делает progress”. Он может зависнуть внутри (deadlock в коде, зависший внешний вызов, stuck event loop) — в этом случае backend в
pg_stat_activityвсё ещё может быть виден. Heartbeat решает именно это: “если давно не пинговал — считаем мёртвым”, даже если TCP/процесс жив.Спасибо за идею!
Спасибо! Возьму на заметку