Здравствуйте, AlexGin, Вы писали:
AG>Так как БД представляет собой директорий "data" (с вложенными поддиректориями и файлами) — то первый вопрос:
Нормальные люди экспортируют/импортируют базу через pg_dump/pg_restore.
AG>Как настроить сервер, установленный в ОС Windows 10 Pro, на работу с данным каталогом?
Я думаю тебе проше будет сделать так:
1. Штатно устанавливаешь PostgreSQL её инсталятором.
2. Выполняешь первый запуск.
3. Останавливаешь сервер СУБД.
4. В директории куда установил СУБД папку data меняешь на свою директорию (старую Data переименовываешь, новую копируешь на её место).
5. Сравниваешь права ntfs старой и новой data — и делаешь у новой такие же, как у сделанной инсталятором.
6. Штатно запускаешь СУБД.
Если версии сервера СУБД и его разрядность (32/64 — обрати внимание) идентичны тому, где твоя папка была раньше — все заработает.
AG>Так, предположим, что база у меня в папке C:\TEMP\ttt\data — как "скормить" этот путь серверу?
Указать путь при сборке из исходников, указать переменную окружения PGDATA, указать в файле postgresql.conf или через параметр командной строки -D
AG>Как проверить, с каким каталогом данных работает в данный момент сервер?
Использовать pgsql — подконектится к работающему экземпляру СУБД и выполнить SQL запрос:
SHOW data_directory;
AG>Как правильно прописать путь к "data" и проконтролировать, что новый путь вступил в силу?
Замени своим каталогом уже существующий. Чё мучатся то?
AG>Второй вопрос (так как каталог "data" имеется, а пароль — нет): установка работы без пароля — судя по описанному здесь: AG>https://stackoverflow.com/questions/18587710/change-reset-postgresql-user-password-on-windows-7 AG>- установить опцию "trust" в файле pg_hba.conf в каталоге "data"? Верно?
Да, все верно.
AG>И наконец, такой вот вопрос: если у прежнего пользователя БД она работала с сервером Win32 (x86), могу ли я AG>запустить под сервером x64 или нет?
Конечно. Сначала запускаешь под x86 туже версию. Делаешь для базы данных pg_dump. Сносишь все это, ставишь x64 (можно версию поновее/старее) и выполняешь pg_restore.
Я может и путаю, но мне казалось у postgres-а журналы тоже сильно завязаны на архитектуру.
Здравствуйте, AlexGin, Вы писали:
AG>Да, я в курсе, что есть родной драйвер. AG>Но (ИМХО) приимущество QODBC — если будет миграция БД на MS SQL Server, я обойдусь минимальными правками в коде.
Если вы Qt-шными SQL-классами пользуетесь, то править вроде ничего и не надо будет (кроме подключения).
AG>В чем же приимущество "родного" PostgreSQL драйвера?
Не знаю, может скорость
AG>P.S. Насчёт кроссплатформенности проекта и работы под Linux — скорее всего НЕ актуально (актуально только Windows).
Тут может быть большой плюс в удобстве разработки: разворачивать постгрес в каком-нибудь докере или виртуальной машине — дело секунд.
Нужен скрипт на 3 строчки а-ля:
Здравствуйте, AlexGin, Вы писали:
AG>Сторонняя программа очень узко-специализированная, разработанная под Windows (x86), несколько лет назад. AG>Там в БД — всё заточено именно под PostgreSQL 9.4 (попытки применить более новую версию — проваливаются). AG>От меня требуется — сделать своё приложение, работающее с этой самой БД, которое будет лучше имеющегося
Скорей не в заточке дело, а в холодных бэкапах. У Postgresql каталог данных железно завязан на версию ПО, у остальных СУБД с этим проще.
Т.е. если ты саму базу перенесешь через pg_dump/pg_restore — скорей всего все заработает на новой версии.
С самим переносом могут быть небольшие сложности — но это будет всякая мелочь, которую по текстам ошибок можно будет быстро подправить. Но более вероятно — все перенесется без ошибок.
С>>А то, я вижу, вам тут уже линуксы советуют, а между тем постгрес замечательно работает на виндах, ставится штатным инсталлятором, админится штатной админкой и так далее.
AG>Я в курсе данной ситуации. Насчёт линуксов — знаком с данной ОС и иногда использую её (Ubuntu 16). AG>Но пока, я не знаю, насколько она мне актуальна и полезна именно для данной задачи.
Я в целом не сторонник применения PostgreSQL под Windows — именно на ней лучше MS SQL Server/Oracle/SQLite/MySQL.
Но в целом это именно порт, т.е. по функциональности он неотличим от Linux версии. Просто могут быть мелкие косяки — вроде сложностей с кодировками.
И напомню про бэкапы базы)) Самолично с фейлами постргреса не сталкивался — у нас на Linux он работает очень хорошо, всем довольны. А вот у коллег были data corruped, которые ещё и не сразу обнаруживались.
Здравствуйте, AlexGin, Вы писали:
m2l>>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
AG>pg_ctl — вот описан: AG>https://stackoverflow.com/questions/36629963/how-to-start-postgresql-on-windows
Обрати внимание на параметр -l/--log он влёт решает твою проблему с кодировками. Еще при установке можно было указать английскую локаль (или подправить её в postgresql.conf) и сообщения будут на латинице — проблема кодировки исчезнет. Ещё можно выполнить chcp 1251 перед выполнением команды. Удостоверься, что консоль запущена с правами администратора. По самой команде, лучше делать restart fast.
AG>Кстати, именно им (и ещё какой-то матерью) мне удалось пару недель назад как-то установить это "чудо" на одном из компов
pg_ctl по сути просто обертка над https://postgrespro.ru/docs/postgresql/9.4/app-postgres (и ещё initdb).
Но я призываю тебя, все-же получить логи в файлах/eventlog/настроенной консоли. Ну ведь реально, постгресс не уникален в своих бедах с кодировкой в виндовом терминале, совсем чуть-чуть и у тебя список ошибок на которые он жалуется. Эти ошибки вставляешь в stackoverflow, советы перепроверять по postgrespro.ru/docs и выполняешь. Это действительно просто.
Здравствуйте, AlexGin, Вы писали:
AG>Вот, кстати, нашел некоторые рекомендации по данному вопросу: AG>https://stackoverflow.com/questions/36629963/how-to-start-postgresql-on-windows AG>там рекомендуют делать через pg_ctl.exe — это правильно?
Похоже на правду (но я это делал последний раз лет 7 назад и в основном на линухе).
AG>Насчёт pg_restore — я нашёл такую информацию: AG>https://stackoverflow.com/questions/2732474/restore-a-postgres-backup-file-using-the-command-line AG>как я понимаю, это альтернатива работе с "сырым" каталогом "data", причём более цывилизованная. Я верно понял?
Так точно. Это единственный кошерный путь. ЕМНИП, гарантии в совместимости сырых данных на диске нет никаких.
S>>Вроде этот файл отвечает за аутентификацию клиентов. Пароля к "файлам БД" у постргреса нет, за разграничения прав доступа на этом уровне отвечает ОС. AG>Но, тем не менее, если я хочу просматривать БД при помощи утилиты pgAdmin, мне понадобится установить опцию "trust" в файле pg_hba.conf примерно так: AG>
AG># TYPE DATABASE USER ADDRESS METHOD
AG>host all all ::1/128 trust
AG>host all all 127.0.0.1/32 trust
AG>
Совершенно верно: это настройка аутентификации для клиентов, которые подключаются к серверу (hba это "host based authentification"), pgAdmin — клиент и вы говорите, что все клиенты, которые подключаются с локального хоста, могут делать что угодно даже без пароля.
Самому процессу постгреса никакой специальный пароль для доступа к БД не нужен, это все на совести администратора системы (тупо права на запись в папку).
AG>Спасибо за подсказки, уважаемый Skorodum!
Пожалуйста. Еще рекомендую не завязываться на pgAdmin, а стараться использовать CLI — он у постргреса очень продвинутый, с хорошим автодополнением, поэтому большинство пользователей им пользуется, легче найти ответ на вопросы.
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Я так понимаю, что если идёт на версии 9.4, то вроде как должно работать и на 9.6; 10; 11? Или это только в теории?
В теории. На практике я пока не сталкивался, чтобы не работало. Но есть еще 1 момент: бывает софт, который требует конкретную версию или их диапазон, и не хочет работать со старшими. Иногда это частично обосновано, как в упомянутом тобой pgAdmin3, который работает в т.ч. с кишками базы (сейчас 4-й допилили до работоспособного уровня, он поддерживает все современные версии), но иногда это просто вахтеризм разработчиков того софта.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, AlexGin, Вы писали:
AG>Дрброе время суток, уважаемые коллеги!
AG>В процессе работы возникла необходимость установить сервер БД PostgreSQL и работать с БД, предоставленной сторонней компанией. AG>Эта БД, как выяснилось, работает с сервером postgresql-9.4. Именно этот сервер я и пытался установить. AG>В качестве утилиты администрирования — pgAdmin 3-1.22.2. AG>Так как БД представляет собой директорий "data" (с вложенными поддиректориями и файлами) — то первый вопрос: AG>Как настроить сервер, установленный в ОС Windows 10 Pro, на работу с данным каталогом?
Наверное, так в теории возможно, но вроде правильный путь это pg_dump + pg_restore (или как-то так). Что-то мешает так сделать?
AG>Так, предположим, что база у меня в папке C:\TEMP\ttt\data — как "скормить" этот путь серверу? AG>Как проверить, с каким каталогом данных работает в данный момент сервер? AG>Так, например, файл pg_env.bat (в каталоге сервера) AG>имеет строку: AG>
AG> @SET PGDATA=C:\TEMP\ttt\data
AG>
AG>Но проблема этим НЕ решается AG>Как правильно прописать путь к "data" и проконтролировать, что новый путь вступил в силу?
Можно еще посмотреть PGDATA в конфигах или параметрах запуска и их приоритеты.
AG>Второй вопрос (так как каталог "data" имеется, а пароль — нет): установка работы без пароля — судя по описанному здесь: AG>https://stackoverflow.com/questions/18587710/change-reset-postgresql-user-password-on-windows-7 AG>- установить опцию "trust" в файле pg_hba.conf в каталоге "data"? Верно?
Вроде этот файл отвечает за аутентификацию клиентов. Пароля к "файлам БД" у постргреса нет, за разграничения прав доступа на этом уровне отвечает ОС.
AG>И наконец, такой вот вопрос: если у прежнего пользователя БД она работала с сервером Win32 (x86), могу ли я AG>запустить под сервером x64 или нет?
AG>Заранее благодарен за любые советы!
Пожалуйста.
Здравствуйте, AlexGin, Вы писали:
AG>Там в БД — всё заточено именно под PostgreSQL 9.4 (попытки применить более новую версию — проваливаются).
Что за попытки? Через бэкап все должно отлично переноситься, там мало ломающих изменений. Разве что тупой клиент может отказываться работать со старшей версией.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, AlexGin, Вы писали:
S>>Не знаю, может скорость AG>Скорость — в смысле за счёт ухода от промежуточного слоя ODBC подсистемы?
Ну это чисто предположение, если все уже работает и все устраивает, то менять вряд ли что-то стоит.
В процессе работы возникла необходимость установить сервер БД PostgreSQL и работать с БД, предоставленной сторонней компанией.
Эта БД, как выяснилось, работает с сервером postgresql-9.4. Именно этот сервер я и пытался установить.
В качестве утилиты администрирования — pgAdmin 3-1.22.2.
Так как БД представляет собой директорий "data" (с вложенными поддиректориями и файлами) — то первый вопрос:
Как настроить сервер, установленный в ОС Windows 10 Pro, на работу с данным каталогом?
Так, предположим, что база у меня в папке C:\TEMP\ttt\data — как "скормить" этот путь серверу?
Как проверить, с каким каталогом данных работает в данный момент сервер?
Так, например, файл pg_env.bat (в каталоге сервера)
имеет строку:
@SET PGDATA=C:\TEMP\ttt\data
Но проблема этим НЕ решается
Как правильно прописать путь к "data" и проконтролировать, что новый путь вступил в силу?
Здравствуйте, уважаемый Skorodum, Вы писали:
S>Наверное, так в теории возможно, но вроде правильный путь это pg_dump + pg_restore (или как-то так). Что-то мешает так сделать?
Попробую покопать в этом направлении, возможно это и даст что-то полезное.
Спасибо, поищу всё по PGDATA.
S>Вроде этот файл отвечает за аутентификацию клиентов. Пароля к "файлам БД" у постргреса нет, за разграничения прав доступа на этом уровне отвечает ОС.
Но, тем не менее, если я хочу просматривать БД при помощи утилиты pgAdmin, мне понадобится установить опцию "trust" в файле pg_hba.conf примерно так:
# TYPE DATABASE USER ADDRESS METHOD
host all all ::1/128 trust
host all all 127.0.0.1/32 trust
Здравствуйте, AlexGin, Вы писали:
AG>Заранее благодарен за любые советы!
Я бы сделал бэкап базы, поставил нужный сервер, и восстановился из бэкапа, избавившись от кучи ненужных приседаний. Собственно, это и в руководстве рекомендуется, поскольку сами файлы БД в общем случае не переносимы между версиями.
Заодно, вероятно, сможешь взять сервер посвежее, там со времен 9.4 многое наоптимизировали, а совместимость вроде сильно не ломали.
А путь к каталогу под виндой смотри в HKLM\SYSTEM\CurrentControlSet\Services\postgresql*****\ImagePath где ***** могут отличаться по версиям постгри
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Если чуть шаришь в линуксе, я настоятельно порекомендую поставить тот линукс, который стоит у товарищей, которые дали тебе базу в виртуалку и запустить базу там. Вероятно это будет проще.
Здравствуйте, AlexGin, Вы писали:
AG>Заранее благодарен за любые советы!
Вы бы описали ситуацию более детально — что за сторонняя программа, почему 9.4, что от вас требуется, какой результат работы ожидается. А то, я вижу, вам тут уже линуксы советуют, а между тем постгрес замечательно работает на виндах, ставится штатным инсталлятором, админится штатной админкой и так далее.
Здравствуйте, уважаемый Skorodum, Вы писали:
S>Еще рекомендую не завязываться на pgAdmin...
Я не завязываюсь.
На одном из компов, где мне удалось (каким-то чудом) установить и запустить с нашей БД сервер PostgreSQL, я работаю с ним из моего C++ (Qt5) проекта.
Работаю — через ODBC драйвер (со стороны системы) и QODBC со стороны моего приложения.
Очень надеюсь, что благодаря Вашим советам, мне удасться успешно развернуть сервер PostgreSQL на всех компах, участвующих в эксперименте
S>...а стараться использовать CLI — он у постргреса очень продвинутый, с хорошим автодополнением, поэтому большинство пользователей им пользуется, легче найти ответ на вопросы.
Хорошо, постараюсь. Тем более, что непосредственной работы через Администратор — относительно мало, как я уже указывал выше.
Здравствуйте, vsb, Вы писали:
vsb>Если чуть шаришь в линуксе, я настоятельно порекомендую поставить тот линукс, который стоит у товарищей, которые дали тебе базу в виртуалку и запустить базу там. Вероятно это будет проще.
Шарю в линуксе на уровне пользователя, и даже компилирую мои творения в Ubuntu (которую держу и в dual-boot, и в виртуалке).
Но у тех товарищей, что предоставили нам БД, — на всех компах Windows 7
Встречный вопрос — в чём мне поможет Linux для данной стуации?
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, vsb, Вы писали:
vsb>>Если чуть шаришь в линуксе, я настоятельно порекомендую поставить тот линукс, который стоит у товарищей, которые дали тебе базу в виртуалку и запустить базу там. Вероятно это будет проще.
AG>Шарю в линуксе на уровне пользователя, и даже компилирую мои творения в Ubuntu (которую держу и в dual-boot, и в виртуалке). AG>Но у тех товарищей, что предоставили нам БД, — на всех компах Windows 7
Т.е. у них постгрес под виндой? Тогда беру совет назад обычно он под линуксом. А между вендой и линуксом фиг знает какие отличия в дата-файлах.
AG>Встречный вопрос — в чём мне поможет Linux для данной стуации?
Здравствуйте, Слава, Вы писали:
С>Вы бы описали ситуацию более детально — что за сторонняя программа, почему 9.4, что от вас требуется, какой результат работы ожидается.
Сторонняя программа очень узко-специализированная, разработанная под Windows (x86), несколько лет назад.
Там в БД — всё заточено именно под PostgreSQL 9.4 (попытки применить более новую версию — проваливаются).
От меня требуется — сделать своё приложение, работающее с этой самой БД, которое будет лучше имеющегося
С>А то, я вижу, вам тут уже линуксы советуют, а между тем постгрес замечательно работает на виндах, ставится штатным инсталлятором, админится штатной админкой и так далее.
Я в курсе данной ситуации. Насчёт линуксов — знаком с данной ОС и иногда использую её (Ubuntu 16).
Но пока, я не знаю, насколько она мне актуальна и полезна именно для данной задачи.
P.S. На мой взгляд — постгрес отвратительно работает — то есть: через пень колоду
Здравствуйте, AlexGin, Вы писали:
AG>На одном из компов, где мне удалось (каким-то чудом) установить и запустить с нашей БД сервер PostgreSQL
Ну значит dump/restore доступен и можно запускать везде и любые версии.
AG>я работаю с ним из моего C++ (Qt5) проекта. Работаю — через ODBC драйвер (со стороны системы) и QODBC со стороны моего приложения.
У Qt родной драйвер из коробки для PostgreSQL есть, я его всегда использовал. Про плюсы-минусы по сравнению с ODBC не скажу.
AG>Очень надеюсь, что благодаря Вашим советам, мне удасться успешно развернуть сервер PostgreSQL на всех компах, участвующих в эксперименте
Здравствуйте, Skorodum, Вы писали:
S>Ну значит dump/restore доступен и можно запускать везде и любые версии.
+100500
Похоже — что это самый правильный, для данной ситуации, вариант.
Но тем не менее, если товарищи опять передадут "сырую" (новую версию) БД, хотелось бы не очень долго "плясать с бубном"
S>У Qt родной драйвер из коробки для PostgreSQL есть, я его всегда использовал. Про плюсы-минусы по сравнению с ODBC не скажу.
Да, я в курсе, что есть родной драйвер.
Но (ИМХО) приимущество QODBC — если будет миграция БД на MS SQL Server, я обойдусь минимальными правками в коде.
В чем же приимущество "родного" PostgreSQL драйвера?
P.S. Насчёт кроссплатформенности проекта и работы под Linux — скорее всего НЕ актуально (актуально только Windows).
Каюсь, что попытки были через "сырой" директорий "data"
Ops>Через бэкап все должно отлично переноситься, там мало ломающих изменений. Разве что тупой клиент может отказываться работать со старшей версией.
Обязательно попробую!
Сообщу здесь — о результате.
P.S. Я так понимаю, что если идёт на версии 9.4, то вроде как должно работать и на 9.6; 10; 11? Или это только в теории?
Здравствуйте, уважаемый Skorodum, Вы писали:
S>Если вы Qt-шными SQL-классами пользуетесь, то править вроде ничего и не надо будет (кроме подключения).
+100500
Выделенное — совершенно верно.
S>Не знаю, может скорость
Скорость — в смысле за счёт ухода от промежуточного слоя ODBC подсистемы?
S>Тут может быть большой плюс в удобстве разработки: разворачивать постгрес в каком-нибудь докере или виртуальной машине — дело секунд. S>Нужен скрипт на 3 строчки а-ля: S>
Здравствуйте, уважаемый m2l, Вы писали:
m2l>Я думаю тебе проше будет сделать так:
Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется!
m2l>1. Штатно устанавливаешь PostgreSQL её инсталятором. m2l>2. Выполняешь первый запуск. m2l>3. Останавливаешь сервер СУБД. m2l>4. В директории куда установил СУБД папку data меняешь на свою директорию (старую Data переименовываешь, новую копируешь на её место). m2l>5. Сравниваешь права ntfs старой и новой data — и делаешь у новой такие же, как у сделанной инсталятором. m2l>6. Штатно запускаешь СУБД — СЕРВЕР НЕ ЗАПУСКАЕТСЯ!!!
Вот такая картинка:
P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый m2l, Вы писали:
m2l>>Я думаю тебе проше будет сделать так: AG>Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется!
1. Ты точно уверен, что версия PostgreSQL совпадает с исходной? Это не Оракл, тут версии при переносе каталога data должны быть один в один.
2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех?
3. Смотри, возможно таланты, что дали тебе такой бэкап ещё что-то намудрили. Замени оригинальный data своим, а потом из оригинального (копия того, что сделал инсталятор) возьми файлы postgresql.conf, pg_ident.conf, pg_hba.conf — и ими подмени файлы из бэкапа в data. Это глобальные настройки СУБД, они непосредственно к базе данных не привязаны. Поэтому ты возьмешь их рабочие экземпляру из копии инсталятора и заменишь экземпляры в неизместном состоянии от своего бэкапа.
4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"?
AG>Вот такая картинка: Смотри, такая картинка происходит
Попробуй проверить права, заместить *.conf файлы внутри data, а потом посмотреть, что за ошибки пишутся в лог.
AG>P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Ну так для этого мы её и переименовали, а не удалили
Здравствуйте, AlexGin, Вы писали:
m2l>>Я думаю тебе проше будет сделать так: AG>Проделывал это раз 100 за сегодня — и на работе и на моём ноуте! Ситуация повторяется! AG>Вот такая картинка: AG>P.S. Возвращение к исходной папке данных (переименованием папок) — позволяет запустить сервер БД.
Попробуй выполнить что я написал выше, но ещё подумай о варианте взять нормальную копию базы данных.
Перенос холодного бэкапа — это один из нескольких штатных способов для Oracle. Это штатной, но не очень рекомендуемый способ для SQL Server. Но даже в них эта операция требует чуть больших знаний и опыта, чем простые impdp/expdp или backup database/restore. А для PostgreSQL переноса каталога data для копирования БД вообще-то не предполагается в принципе. Этот способ обычно используют когда исходный сервер СУБД вышел из строя, бэкапов нет, а данные спасти надо. И потенциально можно поиметь очень много граблей в этом деле. Поэтому оцени — возможно потребовать выгрузку исходной базы данных через pg_dump будет проще? Так сказать действовать административными, а не техническими методами.
В общем, посвятив день борьбе с проблемой установки этого "чуда" на Windows, могу с уверенностью предположить — что эта СУБД неудачная
По крайней мере — для Windows систем.
Ситуация повторялась с точностью один в одни как на стационарном компе, так и на ноуте (Windows 10 x64 Pro — в обоих местах).
1) Остановив службу и заменив директорий "data" на мой (переименовав старый), — получаем НЕзапускаемый сервер с невразумительной ошибкой: http://rsdn.org/forum/db/7439201.1
2) На единственном месте, где (чудом) удалось пару недель назад эту БД запустить, выполнение бекапа командой:
pg_dump -U postgres -d AICM -f d:/TEMP/aicm.sql
всё-таки создаёт файл aicm.sql (в папке d:/TEMP). Это — единственный положительный момент
Вот только восстановить данную базу — к сожалению, нигде НЕ возможно
a) Выполнение команды:
psql -U postgres -f d:/TEMP/aicm.sql
(при работающей службе postgresql-9.4) — проводит некоторую работу, которая так и НЕ создаёт никакой новой базы.
b) Выполнение команды:
pg_restore -U postgres -f d:/TEMP/aicm.sql
хоть при работающей службе, хоть при остановленной — вызывает "зависание" данной команды.
Только "Ctrl + C" с клавиатуры — вызывает выход из этой команды.
3) Выполнение команды:
pg_ctl -D "D:\PSG_SQL\data" restart
с целью переноса рабочей папки
при работающей службе postgresql-9.4 — вызывает такое вот сообщение и зависание:
Опять "Ctrl + C" с клавиатуры
Кто может — укажите, пожалуйста, где кривость моих рук и есть ли здесь она?
Здравствуйте, m2l, Вы писали:
m2l>1. Ты точно уверен, что версия PostgreSQL совпадает с исходной? Это не Оракл, тут версии при переносе каталога data должны быть один в один.
Да, так как в одном месте — чудо случилось (пару недель назад) и у меня как-то
получилось запустить на pg sql 9.4.
Ну и наши бойцы (которые дали мне БД) говорили и писали про версию 9.4 (x86).
m2l>2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех?
Копировал в Total-Comander — с установкой соответствующего check-box-а.
m2l>3. Смотри, возможно таланты, что дали тебе такой бэкап ещё что-то намудрили. Замени оригинальный data своим, а потом из оригинального (копия того, что сделал инсталятор) возьми файлы postgresql.conf, pg_ident.conf, pg_hba.conf — и ими подмени файлы из бэкапа в data. Это глобальные настройки СУБД, они непосредственно к базе данных не привязаны. Поэтому ты возьмешь их рабочие экземпляру из копии инсталятора и заменишь экземпляры в неизместном состоянии от своего бэкапа.
Заменил файлы postgresql.conf, pg_ident.conf, pg_hba.conf — теми, что в запускаемой (рабочей) конфигурации, вернулся к моей конфигурации — ситуация та же, что описывал ранее
m2l>4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"?
нашел этот лог — просматриваю...
Если служба НЕ стартовала, лог пустой — что в общем и следует ожидать.
Здравствуйте, AlexGin, Вы писали:
AG>В общем, посвятив день борьбе с проблемой установки этого "чуда" на Windows, могу с уверенностью предположить — что эта СУБД неудачная AG>По крайней мере — для Windows систем.
Скорей просто несколько не user friendly))
AG>1) Остановив службу и заменив директорий "data" на мой (переименовав старый), — получаем НЕзапускаемый сервер с невразумительной ошибкой:
PostgreSql не рассчитан на перенос данных простым копированием data. Без проблем это возможно только для идентичных программных окружений. В некоторых случаях вообще невозможно.
И невразумительное ошибку даёт менеджер служб. Постгрес свои ошибки, в зависимости от настроек postgresql.conf пишет в файл/консоль/event log. И соответственно их надо там читать.
AG>2) На единственном месте, где (чудом) удалось пару недель назад эту БД запустить, выполнение бекапа командой: AG>
AG>всё-таки создаёт файл aicm.sql (в папке d:/TEMP). Это — единственный положительный момент AG>Вот только восстановить данную базу — к сожалению, нигде НЕ возможно AG>a) Выполнение команды: AG>
AG> psql -U postgres -f d:/TEMP/aicm.sql
AG>
AG>(при работающей службе postgresql-9.4) — проводит некоторую работу, которая так и НЕ создаёт никакой новой базы.
Во первых есть параметр --verbose , с которым скорей всего будет видно место ошибки.
Во вторых aicm.sql это действительно просто последовательность sql запросов — ты можешь выполнить их и без pg_restore. Отдавать места ошибок и подкорректировать руками.
AG>хоть при работающей службе, хоть при остановленной — вызывает "зависание" данной команды.
Если честно, возможно это одно из мест, где проявляются косяки порта postgresql под windows — не очень он любит штатную консоль. Как раз, такие моменты я имел ввиду, когда писал, что под win, желательно другие СУБД использовать. Как обходной путь попробуй pgAdmin для восстановления из бэкапа.
AG>Только "Ctrl + C" с клавиатуры — вызывает выход из этой команды.
AG>3) Выполнение команды: AG>
AG> pg_ctl -D "D:\PSG_SQL\data" restart
AG>
AG>с целью переноса рабочей папки AG>при работающей службе postgresql-9.4 — вызывает такое вот сообщение и зависание: AG>Image: pg_sql_problem2.jp AG>Опять "Ctrl + C" с клавиатуры
Каталог data категорически нельзя трогать при работающем экземпляре СУБД.
AG>Кто может — укажите, пожалуйста, где кривость моих рук и есть ли здесь она?
Ну, тут скорей складываются отсутствие у тебя опыта, общая неинтуитивность постгреса/СУБД и косяки его порта под Винду.
Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
Здравствуйте, AlexGin, Вы писали:
AG>Да, так как в одном месте — чудо случилось (пару недель назад) и у меня как-то AG>получилось запустить на pg sql 9.4. AG>Ну и наши бойцы (которые дали мне БД) говорили и писали про версию 9.4 (x86).
Ок.
m2l>>2. Ты точно воссоздал права всё права на NTFS или рекуррентно заменил существующие на полный доступ для всех? AG>Копировал в Total-Comander — с установкой соответствующего check-box-а.
Я не уверен, что в процессе не закралась маленькая неточность) Давай, для data добавим Acl для пользователя everyone/все, с правами полный доступ и и поставим галочку заменить права дочерних объектов.
AG>Заменил файлы postgresql.conf, pg_ident.conf, pg_hba.conf — теми, что в запускаемой (рабочей) конфигурации, вернулся к моей конфигурации — ситуация та же, что описывал ранее
Ок, тогда логи.
m2l>>4. Надо читать лог и смотреть, на что ругается. У тебя есть файлы в "C:\Program Files\PostgreSQL\9.4\data\pg_log"? AG>нашел этот лог — просматриваю...
Куда, с какой детализацией и пишется ли вообще зависит от настроек в postgresql.conf из data. Возможно их надо подправить. AG>Если служба НЕ стартовала, лог пустой — что в общем и следует ожидать.
Вот тут ты не прав. Последовательность иная — диспетчер служб стартует процесс, он загружает настройки postgresql.conf и начинает писать логи, пытается подхватить саму базу, фейлится, пишет об этом и почему в лог, завершает работу не возвращая диспетчеру код успешного запуска. Диспетчер говорит тебе, что не смог запустить службу.
Т.е. при правильной настройке лога и правах на запись в него, там будут ошибки из-за которых служба не стартовала.
Здравствуйте, m2l, Вы писали:
m2l>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, m2l, Вы писали:
m2l>>Имхо задача принципиально решаемая. Просто надо включать расширенное логирование, вытягивать коды/тексты ошибок того что происходит и корректировать свои действия под них. И да, эти тексты ошибок там действительно есть)) Ну кроме твоего варианта pg_ctl полагаю.
AG>pg_ctl — вот описан: AG>https://stackoverflow.com/questions/36629963/how-to-start-postgresql-on-windows
AG>Кстати, именно им (и ещё какой-то матерью) мне удалось пару недель назад как-то установить это "чудо" на одном из компов
Доброе время суток, уважаемые коллеги!
Наконец-то удвлось запустить PostgreSQL 9.4.22 на Win-10 Pro
Опишу подробно все мои действия:
0) Удалил всё то, что ставил вчера днем и вечером;
1) На сайте PostgreSQL — имеется архив БИНАРНИКОВ: https://www.enterprisedb.com/download-postgresql-binaries
я решил не ставить через *.msi файл, не брать инсталлятор сервера (один большой *.exe), а просто скачать бинарник: postgresql-9.4.22-1-windows-binaries.zip;
2) Сделал папку: C:\PSG_SQL — в которую и распаковал все содержимое вышеуказанного архива.
Эту папку — расшарил на режим "everyone: read/write";
3) В эту же папку поместил мою "многострадальную" папку "data"
эту папку — также расшарил на режим "everyone: read/write";
4) В папке "data" в файле pg_hba.conf — установлена опция "trust":
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
эта опция установлена в двух строках;
5) В переменных окружения — (user variables) я добавил новую переменную: PGDATA = C:\PSG_SQL\data
после этого добавления — перезагрузился (чтобы оно вступило в силу);
6) Запустив консоль cmd.exe с правами Администратора, и перейдя в директорий C:\PSG_SQL\bin выполнил:
pg_ctl start
выдав немного аброкадабры и латиницы, приложение осталось работать (вроде без ошибок);
7) Установил приложение pgAdmin III v 1.22.2 (файлом pgadmin3.msi) и подключился к серверу,
там увидел все требуемые мне таблицы;
8) Установил драйвер ODBC (файлом psqlodbc_x86.msi), создал ODBC — DSN для 32-х разрядного режима,
убедившись, что cjnnect к серверу БД работает;
9) Запустив мой проект из Visual Studio — убедился что требуемый результат получен
P.S. Моя служба postgresql-9.4 теперь НЕ видна в общем окне списка служб Windows, но тем не менее — она работает!
В окошке pgAdmin-a (в SQL Editor) ввожу:
SHOW data_directory;
Получаю верный путь: C:/PSG_SQL/data
здесь разделители — в стиле Linux
Здравствуйте, AlexGin, Вы писали:
AG>...имеется архив БИНАРНИКОВ: AG>https://www.enterprisedb.com/download-postgresql-binaries AG>я решил не ставить через *.msi файл, не брать инсталлятор сервера (один большой *.exe), а просто скачать бинарник: AG>postgresql-9.4.22-1-windows-binaries.zip;
Может это не совсем правильно, так как при установке из файла *.msi и "натравливании" инсталлятора на мою "многострадальную" папку "data" C:\PSG_SQL\data
для версии 9.4.22-1 было сообщение, о несовместимости данных.
В то же время, для версии 9.4.21-1 — всё проходит отлично!
Возможно, корректнее было бы устанавливать архив: postgresql-9.4.21-1-windows-binaries.zip;
