У меня было такое в службах 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", и он работает просто отлично.
Есть идеи?
Команда 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, и вуаля, все заработало.
Это случилось со мной, потому что я установил каталог данных в такое место, куда учетная запись пользователя postgres windows не имела доступа.
Я столкнулся с той же проблемой после перемещения вручную файлов данных базы данных (каталог PG_DATA) без воссоздания всех необходимых разрешений.
Вот как я решил свою проблему:
cacls "c:\path\to\old\pgdata\dir"
cacls "d:\path\to\NEW\pgdata\dir"
Найдите различия между пользователями и/или разрешениями, затем синхронизируйте их.
Примечание: Я обнаружил, что проще использовать explorer
для шага синхронизации, чем использовать cacls
непосредственно из командной строки.
У меня была такая проблема в Windows после сбоя системы. Выполнение первой команды показало недопустимые данные в C:\Program Files\PostgreSQL\9.1\data\postmaster.pid
. Удаление этого файла помогло. Ссылка.
Если вы изменили 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
Вам нужно проверить файлы журналов и журнал событий windows, чтобы найти хоть какой-то намек на то, в чем проблема. Если там вообще ничего нет, вам нужно открыть что-то вроде Process Monitor и получить стек-трейс того, где он завис.
У меня уже была такая проблема в прошлом, и она заключалась в том, что программа установки не установила правильные разрешения для пользователя, от имени которого должна была работать служба.
откройте pgAdmin III и в правой панели найдите сервер, затем просто щелкните правой кнопкой мыши и подключитесь, введите пароль. после подключения перейдите в браузер и обновите ODOO. Проблема решена.
Смотрите изображение для лучшего понимания