Машина с Windows 7, на которой запущен сервер Postgres 8.4.x, сегодня утром перестала работать должным образом. Ошибки более чем странные:
Средство просмотра событий, большинство из них происходит несколько раз и происходит при загрузке или попытке запустить / остановить сервер.
PostgreSQL - Error - Se agotó el tiempo de espera al inicio del servidor
2013-12-03 21:33:32 GMT FATAL: el archivo de bloqueo «postmaster.pid» ya existe
2013-12-03 21:33:32 GMT HINT: ¿Hay otro postmaster (PID 2952) corriendo en el directorio de datos «C:/Program Files (x86)/PostgreSQL/8.4/data»?
pg_ctl: no se pudo encontrar el ejecutable postgres
2013-12-03 18:46:34 CET FATAL: no se pudo crear ningún socket TCP/IP
pg_dump может сделать полную резервную копию (поэтому я сделал это, прежде чем возиться), несмотря на то, что служба все еще не отмечена как работающая.
Я попытался удалить pid-файл, так как я считаю его рекомендованным везде, но это не помогло.
Просмотр файлов журнала действительно обнаружил настоящую ошибку в запросе, но это все еще не решает проблему, заключающуюся в том, что я не могу остановить или запустить службу postgres. Изменить: и исправление этого недопустимого запроса ничего не решает, приложение все равно вылетает.
Соответствующие части pg_hba.conf:
host all all 127.0.0.1/32 md5
host all all 192.168.0.0/16 md5
host all all fe80::/48 md5
Некоторые журналы (другие имеют эквивалентное содержание):
http://pastebin.com/v9gtiDmJ
http://pastebin.com/wxYr8TUM
Во-первых, из любви к вашим данным ПОЖАЛУЙСТА прекратить вносить изменения в систему.
Вам необходимо полностью проанализировать проблему, прежде чем начинать вносить изменения, иначе вы рискуете усугубить проблему.
Как вы догадались Postgres работает в вашей системе - мы знаем это, потому что pg_dump работает. Если бы не было сервера Postgres pg_dump не с чем было бы поговорить.
Это означает, что ваша проблема (в том виде, в котором она существовала в начале) полностью косметический (так что Service Manager думает, что он не работает - кого это волнует ?! Он работает, и это то, что важно).
«Простое решение» в этом случае - просто игнорировать ситуацию - если она не сломана, не ломайте ее!
Следующее простое решение (если для вас важно мнение менеджера по обслуживанию) - вручную остановить Postgres, используя pg_ctl, затем перезапустите его с помощью диспетчера служб.
Это больше не вариант для вас, потому что вы удалили файл PID. Сейчас pg_ctl не знает, о каком процессе Postgres сигнализировать. (В Unix это легко исправить - просто подайте сигнал процессу Postgres с наименьшим PID для завершения, и база данных отключится. Я не уверен, какой эквивалент есть в Windows, но если вы это сделаете, вы можете это сделать.)
Последний вариант - перезагрузка. Это то, что вы бы сделали, если бы два вышеуказанных варианта не смогли заставить Service Manager сообщить статус, соответствующий действительности.
В Unix это должно корректно завершить работу Postgres, когда все системные процессы получат TERM signal, и я предполагаю, что Windows имеет аналогичное поведение (но даже если это не так - Postgres рассматривает это как сбой и восстанавливается при следующем запуске).
Поскольку вы обновили установку Postgres, теперь вам нужно выполнить второй или третий вариант - вы не можете оставить свою систему в ее текущем состоянии.
В настоящее время вы находитесь в состоянии, когда двоичные файлы / библиотеки на диске не соответствуют запущенным, и это не хорошее положение. Чтобы убедиться, что ваша система находится в известном и последовательном состоянии, вы должен перезапустите Postgres.
В вашем случае я бы предложил остановить сервер базы данных, переустановить двоичные файлы (чтобы убедиться, что ни один из них не был пропущен, потому что они были заблокированы), а затем запустить его снова. Обычно вы никогда не обновляете двоичные файлы во время работы Postgres - сначала вы его закрываете. По крайней мере, в системах Unix большую часть времени вы можете «избежать неприятностей», но зачем рисковать, что что-то пойдет не так?