Невозможно запустить PostgreSQL в качестве службы Windows

У меня было такое в службах Windows:

C:/Program Files/PostgreSQL/8.4/bin/pg_ctl.exe runservice -N "postgresql-8.4" -D "D:/PostgreSQL/8.4/data" -w

Он никогда не завершает выполнение. Но если я сделаю это в оболочке dos:

C:/Program Files/PostgreSQL/8.4/bin/pg_ctl.exe start -N "postgresql-8.4" -D "D:/PostgreSQL/8.4/data" -w

Обратите внимание, что я только изменил "runservice" на "start", и он работает просто отлично.

Есть идеи?

Valeriu
56173
Редактировал вопрос 26-го ноября 2021 в 3:18
Erwin Brandstetter
Редактировал вопрос 14-го января 2012 в 6:50
Программирование
postgresql service
9-го августа 2009 в 11:48
148 просмотров

Команда runservice может быть выполнена только менеджером служб

для того, чтобы исправить мой localhost windows 7 для запуска postgres в качестве службы Я использовал следующую команду для запуска

 pg_ctl -D "C:\Program Files\PostgreSQL\9.1\data" start

Затем проверил статус на наличие ошибок

 pg_ctl -D "C:\Program Files\PostgreSQL\9.1\data" status

Если вы получаете ошибку 1063, то, скорее всего, дело в разрешениях, я выполнил следующую команду

 cacls "C:\Program Files\PostgreSQL\9.1\data" /E /T /C /G postgres:F

затем повторил запуск/статус, он показал все в порядке, но все равно диспетчер служб не запускал службу.

Поэтому в Services->postgresql->options->logon я установил вход в систему как учетную запись Local system вместо пользователя postgres, и вуаля, все заработало.

Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:19
Комментарии (2)

Это случилось со мной, потому что я установил каталог данных в такое место, куда учетная запись пользователя postgres windows не имела доступа.

Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:19
Комментарии (3)

Я столкнулся с той же проблемой после перемещения вручную файлов данных базы данных (каталог PG_DATA) без воссоздания всех необходимых разрешений.

Вот как я решил свою проблему:

1. Проверьте разрешения в старом каталоге PG_DATA:

cacls "c:\path\to\old\pgdata\dir"

2. Проверьте права доступа к новому каталогу PG_DATA:

cacls "d:\path\to\NEW\pgdata\dir"

3. Сравните результаты 1. и 2.

Найдите различия между пользователями и/или разрешениями, затем синхронизируйте их.

Примечание: Я обнаружил, что проще использовать explorer для шага синхронизации, чем использовать cacls непосредственно из командной строки.

Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:20
Комментарии (0)

У меня была такая проблема в Windows после сбоя системы. Выполнение первой команды показало недопустимые данные в C:\Program Files\PostgreSQL\9.1\data\postmaster.pid. Удаление этого файла помогло. Ссылка.

Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:19
Комментарии (0)

Если вы изменили pg_hba.conf, возможно, вы пропустили что-то в файле. Например, в этом файле после IP должен быть CIDR. Это должно быть что-то вроде 192.168.1.100/32.

Если вы забыли поставить 32, то сервер не перезагрузится.

Исследование журналов запуска может быть подсказкой. В случае, если проблема в pg_hba.conf, вы можете увидеть что-то вроде этого:

2018-11-13 00:39:34.841 PST [8284] FATAL:  could not load pg_hba.conf
2018-11-13 00:39:34.842 PST [8284] LOG:  database system is shut down
Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:20
Комментарии (0)

Вам нужно проверить файлы журналов и журнал событий windows, чтобы найти хоть какой-то намек на то, в чем проблема. Если там вообще ничего нет, вам нужно открыть что-то вроде Process Monitor и получить стек-трейс того, где он завис.

Комментарии (0)

У меня уже была такая проблема в прошлом, и она заключалась в том, что программа установки не установила правильные разрешения для пользователя, от имени которого должна была работать служба.

Комментарии (0)

откройте pgAdmin III и в правой панели найдите сервер, затем просто щелкните правой кнопкой мыши и подключитесь, введите пароль. после подключения перейдите в браузер и обновите ODOO. Проблема решена.

Смотрите изображение для лучшего понимания

Valeriu
56173
Редактировал ответ 26-го ноября 2021 в 3:20
Комментарии (0)