Добрый день.
Первое и самое разумное решение - диагностировать проблему в коде dblink и исправить (ещё поможет сделать вклад в проект). Но нужно знать С.
Вариант #2: можно использовать background worker, который пишется как дополнение, стартует вместе с базой (доступен с 9.3, тоесть Ваш вариант) и отслеживает подобные "мёртвые" соединения и убивает их. Опять нужно знать совсем чуточку С.
Алексей
Thursday, 24 July 2014, 10:37PM +03:00 from Aleksey Smart <a4irkin@gmail.com>:
Доброго времени суток, господа!
Решил обратиться к вам за помощью, потому что не смог найти решения своей проблемы.
Я создал подобие кластера из нескольких машин с PostgreSQL (9.3), каждая машина может обращаться за данными к другим машинам посредством dblink, я не стал использовать postgres_fdw, потому что предпочитаю создавать более высокоуровневый api посредством функций, а через Foreign Data Wrapper можно обращаться только к таблицам. Созданный мною кластер хорошо себя показал на этапе тестирования, но после перевода в продакшн обнаружились серьезные проблемы. Постепенно сервера заполнялись замороженными активными соединениями, переполняя пул. PostgreSQL не хотел перезагружаться, приходилось убивать процессы принудительно. После некоторых опытов выяснилось, что дело в dblink. Если возникает deadlock (поймать его с dblink можно легко) или же пропадает связь с удаленным сервером, dblink вешает процесс соединения намертво. Даже экспериментируя в psql мне удавалось повесить процесс. Что удивительно, statement_timeout пользователя не действует в этом случае, процесс висит вечно. Это совсем плохо, в надежде, что в fdw все исправили, я попробовал и получил то же самое. Я не знаю что происходит на удаленном сервере, но я хочу иметь хоть какой-то рабочий таймаут.
Как же теперь реализовать кластер не получив зависшие процессы?
---
Алексей
