Postgresql не устанавливается на windows 2008

This page is intended to help people collect information to troubleshoot problems with the PostgreSQL Installers supplied by EnterpriseDB.

Many problems have already been identified and fixed, so make sure you’re using the installer for the latest point-release of PostgreSQL before reporting a problem.

Because some problems can’t be fixed in the installer, but are issues with the Windows installation or how it is being used, there is also a list of frequently asked questions and frequently encountered problems with PostgreSQL on Windows. Please read the common installation errors section, or preferably the whole document. You’ll probably save some time and hassle by doing so.

If you’ve tried all that, and you’re still having problems getting PostgreSQL installed, please read on to find out how you can collect the information we need to be able to help you with installation problems.

Make sure you’re installing on a supported platform

See the installer download page and (for Windows) the Running & Installing PostgreSQL On Native Windows for platform support details.

Please do not ask the mailing list for help with installation on unsupported Windows platforms. However, one of the paid PostgreSQL consultants, or EnterpriseDB (who make the PostgreSQL installer) may be able to help you on a paid basis.

Try again without your virus scanner or 3rd-party firewall

The Windows FAQ discusses potential issues with antivirus software and 3rd-party firewalls. If you’re encountering any installation issues, please try again with your virus scanner uninstalled (not just disabled) to see if the problem goes away. If it does, please report the fact to the mailing list and to the vendor of your antivirus product.

Read about other common installation problems

Before reporting a problem, please read the windows FAQ to see if your problem is one we’ve already seen and found a workaround or fix for.

Reporting an installation error

To be able to help you with an installation problem, we will need you to collect some basic details about your computer and the problem. Please see the instructions below.

Note down the basic information about your system

Any problem report must include:

• The exact words of any error message you see when the installation fails
• The exact version of PostgreSQL you are installing
• Whether you installed a 32-bit or 64-bit release of PostgreSQL
• The operating system and version you are using, eg:
  • «Windows XP Professional with Service Pack 3»
  • «Mac OS X 10.4.2»
  • «Fedora Core 14»
• Whether you are running a 32-bit or 64-bit version of your operating system
• How you ran the installer. Command-line arguments, what user account you ran it from, etc.
• What antivirus and/or software firewall products you have installed, if any, even if they are disabled
• Which, if any, of the troubleshooting instructions you have already tried
• Whether a previous version of PostgreSQL was installed, and if so:
  • whether you uninstalled it before running the new installer
  • If you uninstalled a previous version, whether you did it with the uninstaller or some other way
  • Whether you removed the postgres user/service account when you uninstalled
• Additional details and platform-specific information as described below

Collect the installer log file

The installer creates a log file in the system ‘temp’ directory. This will log all manner of data about the installation, and is invaluable when troubleshooting. The log will be called install-postgresql.log if the installation completed successfully. If not, the installer may not have been able to rename it, in which case the name will be either bitrock_installer.log or bitrock_installer_xxx.log, where xxx is a number (actually the process ID of the installation attempt).

On Linux and Mac systems, the logfile will almost always be found in the /tmp/ directory.

On Windows, the easiest way to find the logfile is to click Start -> Run, enter %TEMP% in the box and then click OK (these instructions apply to Windows XP and 2003 — adjust as necessary for other versions).

Get the contents of the PostgreSQL server error log

The PostgreSQL server has its own error log. This may not exist if installation failed early on, but it can be very informative for errors that happened later in installation. You can find it in the «pg_log» folder inside the data directory you chose for PostgreSQL. If it exists, please include it in any problem reports.

Windows users must collect additional Windows-specific details to help troubleshoot installation issues:

• (On Windows Vista and Windows 7): The UAC security level
• Whether you started the installer by logging in as Administrator, started it from from your own normal user account, or ran it using the «Run As Administrator» menu option.
• Whether your computer is a part of a Windows domain. Home computers usually are not, business computers usually are.
• Whether your computer and network has any Group Policy configured. If you’re on a corporate windows domain you probably have group policy and need to ask your network administrator for details about it.

Windows: Check for messages in the Windows event log

Please check the Windows Event Viewer for messages that might be related to installation problems or service startup problems.

TODO: detail on how to collect and save events.

Windows: Check what Group Policy, if any, is active on your computer

TODO: instructions for collecting domain and local group policy.

Windows: Take a copy of the environment variables set on the computer

Open a command prompt and run «set». Then copy and paste the results into your problem report.

I’d be better to collect the «all users» environment from the system control panel, but it’s not easy to just dump this information.

Вариант использования в качестве сервера баз данных PostgreSQL на windows платформе не очень популярен, но имеет место быть как правило, когда необходимо хоть как-то сэкономить на продуктах от MS. Так же существуют специализированные приложения, которые наилучшим образом работают с PostgreSQL. Для 1с существует модифицированная сборка PostgreSQL дающая как уверяют разработчики сопоставимый с MSSQL уровень производительности и отказоустойчивости. Так ли это на самом деле, проверим на практике

1. Установка  PostgreSQL

Качаем с сайта 1с последнюю сборку PostgreSQL 64-bit 9.1.2-1.1C, распаковываем архив, запускаем msi-пакет, тот что без int, имеет не большой размер файла.

Нажимаем Start.

Опции установки оставляем по умолчанию.

Задаем пароль пользователю postgres от которого будет стартовать сервис. Нажимаем Далее. Если установка  PostgreSQL производится впервые, то мастер предложит создать пользователя postgres.

На этапе инициализации БД, выбираем кодировку UTF8. Задаем логин и пароль внутреннему пользователю postgres. Внимание! Пароли пользователя сервиса PostgreSQL  и пароль внутреннего пользователя БД PostgreSQL не должны совпадать. Пароль должен состоять как минимум из четырех символов. Если сервер 1C и  PostgreSQL планируется запускать на разных машинах, то необходимо поставить галочку «Поддерживать соединения с любых IP, а не только с localhost». Нажимаем Далее и еще раз Далее.

Нажимаем еще два раза Далее и дожидаемся окончания установки.

Затем идем в StartAll ProgramsPostgreSQL 9.1.2-1.1C(x64). Запускаем утилиту администрирования pgAdmin III. Пробуем подключится к БД. Вводим пароль, который указывали во время установки.

И получаем следующую ошибку: Error connecting to the server: FATAL: password authentication failed for user «postgres».

Довольно неожиданно, с учетом того, что пароль был набран верно. Решил поковырять pg_hba.conf, но на первый взгляд там все хорошо.

# TYPE   DATABASE     USER                   ADDRESS               METHOD

# IPv4 local connections:
host                   all             postgres               ::1/128                  md5
host                   all             postgres               127.0.0.1/32             md5
host                   all             postgres               192.168.1.0/24         md5

Решил, поменять метод авторизации с md5 на trust. Перезапускаю сервис и снова пробую подключится к БД. На этот раз получаю такое сообщение.

Действительно на сайте pgAdmin доступна уже более новая версия. После чего подключение к БД завершается успехом!!?!! Помнится, ранее md5 не вызывал подобных проблем, видимо данный глюк действительно связан со старой версией pgAdmin’a.

Теперь можем создать базу для нужд 1С, либо сделать это при помощи самой 1С

2. Установка 1C предприятие 8.2.

Для установки отметим, следующие компоненты: 1С:Предприятие, Сервер 1С:Предприятия, Модули расширения веб-сервера, Администрирование сервера 1С:Предприятия.

На этапе, установки «Установить 1С Предприятие как сервис», задаем пароль пользователю USR1C82.

Нажимаем далее, следим за ходом установки  Пользователю USR1CV82  при установке должны быть назначены следующие права:

Вход в систему как сервис (Log on as a service), Вход в систему как пакетное задание (Log on as a batch job). Посмотреть можно в Local Computer PolicyComputer ConfigurationWindows SetingsSecurity SetingsLocal PoliciesUser Right Assigments.

Переходим в оснастку Администрирование серверов 1С Предприятие, смотрим что кластер поднялся, и висит на 1541 порту. На вкладке «Рабочие серверы» так же присутствует наш сервер.

Теперь, можно добавить базу на сервер 1С. Для этого переходим на вкладку «Информационные базы» щелкаемся правой кнопкой и выбираем New — Информационная база. Задаем необходимые параметры для подключения к серверу PostgreSQL. Нажимаем ОК.

Запускаем 1С: Предприятие. Выбираем, добавить существующую информационную базу на сервере.

Далее, задаем параметры для подключения. Нажимаем «Далее» и наконец «Готово».

Операцию по созданию базы, можно проделать напрямую из 1С: Предприятия. Для этого при запуске, выбираем пункт «Создание новой информационной базы».

Для подключения клиентов 1С к серверу извне и работы сервера баз данных, на файрволе, должны быть открыты следующие порты:

Агент сервера (ragent) — tcp:1540 Главный менеджер кластера (rmngr) — tcp:1541 Диапазон сетевых портов, для динамического распределения рабочих процессов — tcp:1560-1591, tcp:5432 — Postgresql.  Создадим правило через стандартный интерфейс, либо с помощью команды:

netsh advfirewall firewall add rule name="1Cv8-Server" dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Теперь с другого компьютера мы спокойно запускаем клиент 1С:Предприятия, добавляем существующую информационную базу newdb. Не забываем про лицензии, программной / аппаратной защиты. Теперь, можем загрузить тест Гилева и померить производительность нашей системы.

На VirtualBox с 1Гб памяти, Dual-Core 2.6 GHz, 319-релиз 1с, тест Гилева выдает — 11.42 баллов, примерно так же как на CentOS. На 16.362 чуть больше 11.60 баллов. Оптимизация настроек при помощи EnterpriseDB Tuning Wizard ощутимого прироста (11.66 и 11.62) не дала, хотя возможно в целом польза от него имеется.

3. Регламентные работы на сервере PostgreSQL. 

Резервное копирование.

Запускаем утилиту администрирования pgAdmin III, щелкаемся правой кнопкой по нужной базе данных. Выбираем »Резервное копирование».

Выбираем формат (Настраиваемый (степень сжатия от 0 до 9), Tar, Простой, Каталог). По степени сжатия, лучше всего сжимает  «настраиваемый формат» любой степени сжатия, затем «каталог», потом «простой» и наконец «tar». Кодировку указываем UTF8, имя роли postgresql. Все дополнительные опции оставляем по умолчанию. Нажимаем кнопку «Резервная копия». В поле «Сообщения» отображается список всех произведенных операций с кодом завершения. Если 0, то успех. Здесь же можно подсмотреть, как запустить подобную операцию из командной строки.

C:Program Files (x86)pgAdmin III1.16pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:Backupsgilev_dump.backup" "newdb"

Соответственно, скрипт автоматического резервного копирования, который мы добавим в планировщик может выглядеть примерно следующим образом:

"C:Program Files (x86)pgAdmin III1.16pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:Backupsgilev_dump_%date:~0,2%_%date:~3,2%_%date:~6,4%.backup" "newdb"

Восстановление.

Для восстановления, выбираем базу, в которую хотим восстановить данные из резервной копии, желательно в пустую. Щелкаемся правой кнопкой и выбираем «Восстановление». Задаем файл бэкапа, имя роли: postgres, нажимаем «Восстановить»

С помощью командной строки:

"C:Program Files (x86)pgAdmin III1.16pg_restore.exe" --host 192.168.1.200 --port 5432 --username "postgres" --dbname "testdb" --role "postgres" --no-password --verbose "G:Backupsgilev_dump_26_09_2012.backup"

где,  testdb — пустая база, в которую восстанавливается архив резервной копии.

Операции по обслуживанию:

Команда VACUUM (Сжатие):

Последовательно чистит все таблицы базы данных, подключенной в настоящий момент, удаляет временные данные и освобождает место на диске. Чаще всего команда VACUUM выполняется именно для получения максимального объема свободного дискового пространства на диске и увеличения скорости доступа к данным.

VACUUM — помечает место, занимаемое старыми версиями записей, как свободное. Использование этого варианта команды, как правило, не уменьшает размер файла, содержащего таблицу, но позволяет не дать ему бесконтрольно расти, зафиксировав на некотором приемлемом уровне. При работе VACUUM возможен параллельный доступ к обрабатываемой таблице. Существует несколько дополнительных опций использования VACUUM : VACUUM FULL,  VACUUM FREEZE,  VACUUM ANALYZE.

VACUUM FULL — пытается удалить все старые версии записей и, соответственно, уменьшить размер файла, содержащего таблицу. Этот вариант команды полностью блокирует обрабатываемую таблицу.

VACUUM FREEZE — Если  VACUUM  FULL удаляет «мусор» из таблиц и перемещает записи так, чтобы таблицы располагались на диске компактно и состояли из наименьшего числа фрагментов, при этом сжатие выполняется долго и блокирует записи,  то VACUUM FREEZE просто удаляет «мусор» из таблиц, но сами записи не перемещает, поэтому выполняется быстрее и не блокирует записи. В настоящий момент эту опцию заменяет autovacuum  — автоматическая сборка мусора в postgresql.conf плюс несколько дополнительных опций расширяющих функциональность:

autovacuum = on # Включает автоматическую сборку мусора.

log_autovacuum_min_duration = -1 # Установка равная нулю регистрирует все действия autovacuum. Минус один (по умолчанию) запрещает вывод в лог. Например, если вы установите значение равное 250 мс, то все действия autovacuum и analyzes, которые работают 250 мс и более, будут заноситься в журнал. Включение этого параметра может быть полезно для отслеживания autovacuum. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

autovacuum_naptime = 10min # Время в секундах через которое база данных проверяется на необходимость в сборке мусора. По умолчанию это происходит раз в минуту.

autovacuum_vacuum_threshold = 1800 # Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM).

autovacuum_analyze_threshold = 900 # Порог на число вставленных, удалённых и изменённых записей в любой таблице по превышению которого запускается процесс анализа (ANALYZE).

autovacuum_vacuum_scale_factor = 0.2 # Процент изменённых и удалённых записей по отношению к таблице по превышению которого запускается сборка мусора.

autovacuum_analyze_scale_factor = 0.1 # То же, что и предыдущая переменная, но по отношению к анализу.

VACUUM ANALYZE —  Если в базе есть таблицы, данные в которых не изменяются и не удаляются, а лишь добавляются, то для таких таблиц можно использовать отдельную команду ANALYZE. Также стоит использовать эту команду для отдельной таблицы после добавления в неё большого количества записей.

Команда ANALYZE (Анализ):

Служит для обновления информации о распределении данных в таблице. Эта информация используется оптимизатором для выбора наиболее быстрого плана выполнения запроса. Обычно команда используется в связке с VACUUM ANALYZE.

Команда REINDEX (переиндексация): 

Используется для перестройки существующих индексов. Использовать её имеет смысл в случае

— порчи индекса;

— постоянного увеличения его размера.

Второй случай требует пояснений. Индекс, как и таблица, содержит блоки со старыми версиями записей. PostgreSQL не всегда может заново использовать эти блоки, и поэтому файл с индексом постепенно увеличивается в размерах. Если данные в таблице часто меняются, то расти он может весьма быстро. Если вы заметили подобное поведение какого-то индекса, то стоит настроить для него периодическое выполнение команды REINDEX. Учтите: команда REINDEX, как и VACUUM FULL, полностью блокирует таблицу, поэтому выполнять её надо тогда, когда загрузка сервера минимальна.

Кризис дело неприятное… и многие пытаясь сэкономить хоть как-нибудь, и устанавливают на Windows PostgreSQL вместо MS SQL.

Хотя если по Вашей компании небольшие обороты, то лучше поставить MS SQL Server 2014 Express, т.к. по опыту PostgreSQL хорошо работает на Linux, на Windows при настройках по умолчанию PostgreSQL работает медленнее MS SQL Server 2014 Express.

Устанавливаем PostgreSQL 9.2.4-1

Скачиваем официальные пакет с сайта 1С (users.v8.1c.ru) и запускаем установку

Отмечаем объекты к установке, если они не отмечены

Устанавливаем «как сервис». Для работы этого сервиса потребуется специальный пользователь. Указываем учетную запись, домен (если имеется) и пароль.

Если пользователь postgres не заведен в системе, то установщик спросит создать пользователя? — жмем да

Перейдем к следующему шагу и укажем Инициализировать кластер БД, порт 5432 и Кодировку UTF8

Если кластер серверов 1С и PostgreSQLна разных машинах, то ставим галочку «Поддерживать подсоединения с любых IP, а не только с localhost». 

Далее — Может возникнуть ошибка «Secondary Logon». Тогда идем в «Администрирование» – «Службы». Стартуем службу «Вторичный вход в систему» или «Secondary Logon»

Далее отметьте галкой необходимые модули, можно установить все, но для 1С они не нужны, я устанавливаю только Adminpack

Если процесс установки завершается без проблем, то вам повезло

Чаще бывают проблемы, решение простое и элегантное (бубен можно оставить):

1. Создать/Изменить учетную запись postgres, включить её в группу Администраторы

2. Выйти из системы и войти в неё под учетной записью postgres

3. Запустить установку PostgreSQL

После установки через меню «Пуск» — «Все программы» запускаем утилиту администрирования «pgAdmin III».

Подключаемся к серверу. Там вводим пароль для пользователя «postgres». Если подключиться удалось, попробуем создать новую базу средствами самой 1С.

Запускаем клиентскую часть 1С. Жмем кнопку «Добавить», ставим галочку «Сервер предприятия 1С». Далее заполняем следующее: сервер базы данных (IP или DNS имя того сервера, куда ставили PostgreSQL) — если тот же, что и кластер 1С, то указываем 127.0.0.1. Имя базы данных: [любое_имя]. Пользователь: «postgres» Пароль: [ваш_пароль_postgres]. Далее.

Проверяем, что база 1С создается успешно.

I’m trying to Install latest version of PostgreSQL and keep running into the below problem which states —

Problem running post-install step. Installation may not be complete
correctly Error running sc start «PostgreSQL 10 Server»:Program ended
with an error exit code

Other important information

• Using windows 10
• I’m not the administrator / user
• Installing version 10 «PostgreSQL-10.3-1-win64-bigsql» file from PostgreSQL website
• Running 64 bit code
• Double clicked and ran the installer file
• Symantec enterprise antivirus is installed

bituninstaller information is below:

Windows Specific Configuration [23:04:29] Windows Actions (services)
Starting service «PostgreSQL 10 Server» Executing sc start «PostgreSQL
10 Server» Script exit code: 1060

Script output:

[SC] StartService: OpenService FAILED 1060: The specified service does not exist as an installed service.

Script stderr: Program ended with an error exit code

Error running sc start «PostgreSQL 10 Server»: Program ended with an error exit code

Problem running post-install step. Installation may not complete correctly

Error running sc start «PostgreSQL 10 Server»: Program ended with an error exit code

[23:16:32] Running pgAdmin post installation actions

Installing pgAdmin3 … Executing C:PostgreSQL_re/pgc install pgadmin3

Script exit code: 0

I’m trying to Install latest version of PostgreSQL and keep running into the below problem which states —

Problem running post-install step. Installation may not be complete
correctly Error running sc start «PostgreSQL 10 Server»:Program ended
with an error exit code

Other important information

• Using windows 10
• I’m not the administrator / user
• Installing version 10 «PostgreSQL-10.3-1-win64-bigsql» file from PostgreSQL website
• Running 64 bit code
• Double clicked and ran the installer file
• Symantec enterprise antivirus is installed

bituninstaller information is below:

Windows Specific Configuration [23:04:29] Windows Actions (services)
Starting service «PostgreSQL 10 Server» Executing sc start «PostgreSQL
10 Server» Script exit code: 1060

Script output:

[SC] StartService: OpenService FAILED 1060: The specified service does not exist as an installed service.

Script stderr: Program ended with an error exit code

Error running sc start «PostgreSQL 10 Server»: Program ended with an error exit code

Problem running post-install step. Installation may not complete correctly

Error running sc start «PostgreSQL 10 Server»: Program ended with an error exit code

[23:16:32] Running pgAdmin post installation actions

Installing pgAdmin3 … Executing C:PostgreSQL_re/pgc install pgadmin3

Script exit code: 0