Postgres не запускается после удаления файлов pg_xlog. Postgresql не запускается
Не запускается служба PostgreSql. Что делать?
Это сообщение предназначено прежде всего для меня лично и для нашей службы поддержки, т.к. проблема подобная описанной ниже происходит с завидной периодичностью и нужно помнить основные шаги по ее решению.
Итак, история начинается с того, что мне 30 декабря в 11-30 звонят с сообщением о том, что у одного из наших клиентов не запускается наша система, поскольку не может подключиться к базе данных (в качестве СУБД у нас используется PostgreSql версии 8.1). Люди объясняют это тем, что час назад вырубило свет и компьютер вырубился некорректно, а после включения – все перестало работать:)
Хорошие пользователи нашей системы знают, где находится кнопка пуск и знают, что в системе не двое часиков “одни с цифрами, а другие песочные”. Поэтому единственное, что удалось сделать по телефону, так это попытаться руками запустить службу СУБД, результат – служба таки не запускается. Пришлось пробрасывать на тот компьютер интернет (на компьютерах, где установлена наша система интернета быть не должно) для возможности удаленного подключения.
После подключения к удаленному компьютеру я попытался запустить службу и получил следующее сообщение: “Служба PostgreSql Database Server 8.1” на “Локальный компьютер” была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если им нечего делать, например, служба журналов и оповещений производительности”. Мда…
Проблема в том, что на тот момент это была единственная доступная информация… Логи PostgreSql пусты, записей в них никаких, в системных логах – тоже пустота.
Отладка служб – процесс не простой, поэтому многие разработчики предусматривают механизмы запуска приложения-службы, как обыкновенного консольного приложения с помощью ключей командной строки. И PostgreSql в этом плане – не исключение; для запуска нужно использовать следующую команду (Hint: эту команду можно запустить только из под неадминистративного пользователя системы, правда, если вы об этом забудете, то PostgreSql очень быстро вам об этом напомнит):
postgres -D "<postgresql data directory>"
Запускаем, и смотрим на сообщение об ошибке. В моем случае это сообщение звучало примерно так:
FATAL - bogus data in lock file "postmaster.pid"
Безусловно, мне повезло, проблема оказалась поправимой. Почему-то указанный файл оказался пустым, и мне понадобилось скопировать его содержимое из рабочего экземпляра СУБД, что не составило особого труда.
Мораль этого сообщения в том, что если база легла, или произошли какие-то другие проблемы с системой, то прежде чем переустанавливать СУБД (или систему целиком) и терять при этом все данные, нужно хотя бы попытаться выяснить в чем проблема, возможно, есть все шансы, что вам удастся восстановить работоспособность не такими радикальными способами.
З.Ы. Всех с наступающим Новым Годом и пожелания того, чтобы ваши системы были стабильными и надежными и не портили ваш сон, но даже если какие-то проблемы и возникали, то у вас всегда были наготове варианты, как с этой ситуацией справиться.
Не стартует служба PostgreSQL
Вопрос: Автозапуск PostgreSQL 9.6 в Debian 8
Приветствую вас!Столкнулся с проблемой старта PostgreSQL 9.6 при загрузке ОС Debian 8.Автозапуск пытаюсь сделать собственным скриптом написанным в соответствии с официальной документацией по СУБД (пп. 18.3 Запуск сервера БД, стр. 565)Содержимое файла \etc\init.d\postgresql:
#!/bin/sh -e ### BEGIN INIT INFO # Provides: postgresql # Required-Start: $local_fs $remote_fs $network $time # Required-Stop: $local_fs $remote_fs $network $time # Should-Start: $syslog # Should-Stop: $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: PostgreSQL RDBMS server ### END INIT INFO PG_PATH="/usr/lib/postgresql/9.6/bin" PGDATA="/var/lib/postgresql/9.6/main" PATH=/bin:/usr/bin:/sbin:/usr/sbin DESC="postgresql daemon" NAME=postgresql DAEMON=/usr/lib/postgresql/9.6/bin/postgresql PIDFILE="$PGDATA/postmaster.pid" SCRIPTNAME=/etc/init.d/"$NAME" case "$1" in start) su - postgres -c "$PG_PATH/pg_ctl start -D $PGDATA -l $PGDATA/log_file.txt" exit 0 ;; stop|status) su - postgres -c "$PG_PATH/pg_ctl $1" ;; kill) su - postgres -c "$PG_PATH/pg_ctl stop -m fast" ;; reboot) $0 kill $0 start ;; *) echo "Используйте: $0 {start|stop|kill|reboot|status}" exit 1 ;; esac exit 0 При запуске из консоли скрипт работает корректно root@debian:~# /etc/init.d/postgresql start сервер запускается root@debian:~# /etc/init.d/postgresql status pg_ctl: сервер работает (PID: 759) /usr/lib/postgresql/9.6/bin/postgres "-D" "/var/lib/postgresql/9.6/main" root@debian:~# /etc/init.d/postgresql stop ожидание завершения работы сервера.... готово сервер остановлен root@debian:~# На скрипт есть ссылки в: /etc/rc0.d -> K02postgresql/etc/rc1.d -> K02postgresql/etc/rc2.d -> S02postgresql/etc/rc3.d -> S02postgresql/etc/rc4.d -> S02postgresql/etc/rc5.d -> S02postgresql/etc/rc6.d -> K02postgresqlПо ней: 1. В /etc/systemd/system/multi-user.target.wants нашел ссылку на unit postgresql.service2. Переписал его следующим образом
[Unit] Description=PostgreSQL RDBMS [Service] Type=forking PIDFile=/var/lib/postgresql/9.6/main/postmaster.pid WorkingDirectory=/usr/lib/postgresql/9.6/bin User=postgres Group=postgres Environment=PGDATA=/var/lib/postgresql/9.6/main OOMScoreAdjust=-100 ExecStart=/usr/lib/postgresql/9.6/bin/pg_ctl start -D /var/lib/postgresql/9.6/main -l /var/lib/postgresql/9.6/main/log_file.txt ExecStop=/usr/lib/postgresql/9.6/bin/pg_ctl stop -m fast ExecReload=/usr/lib/postgresql/9.6/bin/pg_ctl restart -D /var/lib/postgresql/9.6/main TimeoutSec=60 #Restart=always #ExecStart=/bin/true #ExecReload=/bin/true #RemainAfterExit=on [Install] WantedBy=multi-user.targetК стати, здесь используется решение, которое позволяет препятствовать агрессивной работе OOM killer о которой пишется в мануале по postgres. О нем говорится что его невозможно остановить, но оказывается что это возможно, указав OOMScoreAdjust=-1000OOM killer - механизм уничтожения процессов при нехватке памяти, который был реализован на уровне ядра, начиная с Linux 2.6 и новее.
Ещё возможно раскомментировать строчку #Restart=always.В таком случае будет отслеживаться наличие указанного PIDFile и при его отсутствии производиться попытка запуска postgresqlМожно считать это аналогом скрипта из моего предшествующего поста, но с реализацией на уровне системы ))
После изменения unit-файла postgresql.service поочередно выполнил команды для переустановки и проверки его работы
systemctl disable postgresql.service systemctl enable postgresql.service systemctl -l status postgresql.service systemctl start postgresql.service systemctl stop postgresql.serviceПри выключении системы сервер корректно останавливается и при старте ОС Debian 8 автоматом загружается.Убрал костыль, который делал для Cron'а
Если есть недостатки в предложенном решении с радостью выслушаю.
installation - PostgreSQL 9.2.4 (Windows 7) - Служба не запускается, "невозможно загрузить pg_hba.conf"
Я пытаюсь запустить Postgres 9.2.4 в качестве службы в Windows 7. После установки postgres служба работает нормально. Однако после установки postgres в качестве сервера для другой программы служба перестала работать. Когда я пытаюсь запустить сервис сейчас, я получаю сообщение о том, что:
"Служба postgresql-x64-9.2 - PostgreSQL Server 9.2 на локальном компьютере Компьютер начал, а затем остановился. Некоторые службы автоматически останавливаются, если они не используются другими службами или программами".
Когда я пытаюсь запустить программу, которая должна использовать сервер базы данных, я получаю эту ошибку:
"Проблема возникла при попытке войти в систему или создать производственной базы данных. Подробности: не удалось подключиться к серверу; Мог не подключаться к удаленному разъему. Приложение должно теперь закрыть"
Я также столкнулся с этой ошибкой один раз при открытии одной и той же программы:
"Проблема возникла при попытке войти в систему или создать производственной базы данных. Подробности: FATAL: не удалось загрузить pg_hba.conf. приложение должно теперь закрыть."
Я попытался запустить службу, зарегистрированную как локальную системную учетную запись, а также мою собственную учетную запись (в свойствах свойств postgres) безрезультатно. Я также попытался перезагрузить компьютер. После многих проблем в Интернете, я узнал, что хорошо проверить файл pg_log. Вот содержание последней записи pg_log:
2013-05-29 14:59:45 MDT LOG: database system was interrupted; last known up at 2013-05-29 14:58:01 MDT 2013-05-29 14:59:45 MDT LOG: database system was not properly shut down; automatic recovery in progress 2013-05-29 14:59:45 MDT LOG: record with zero length at 0/175BB98 2013-05-29 14:59:45 MDT LOG: redo is not required 2013-05-29 14:59:45 MDT LOG: database system is ready to accept connections 2013-05-29 14:59:45 MDT LOG: autovacuum launcher started 2013-05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:07:00 MDT LOG: local connections are not supported by this build 2013-05-29 15:07:00 MDT CONTEXT: line 1 of configuration file "C:/PostgreSQL/data/pg_hba.conf" 2013-05-29 15:07:00 MDT FATAL: could not load pg_hba.conf 2013-05-29 15:09:03 MDT LOG: received fast shutdown request 2013-05-29 15:09:03 MDT LOG: aborting any active transactions 2013-05-29 15:09:03 MDT LOG: autovacuum launcher shutting down 2013-05-29 15:09:03 MDT LOG: shutting down 2013-05-29 15:09:03 MDT LOG: database system is shut downВ соответствии с многочисленными предложениями в Интернете я попытался изменить верхнюю строку на несколько различных альтернатив (все хосты all trust/host all 127.0.0.1/32 trust/host all 192.168.0.100/24 trust и т.д.). Это имело смысл для меня, поскольку в файле журнала говорилось, что локальные соединения не поддерживаются postgres и также указывают на эту строку. Однако ни одно из моих изменений не повлияло. Я попытался перезагрузить свой компьютер после каждого изменения, но ничего не изменилось.
Когда я искал примеры того, как обычно выглядит файл pg_hba.conf, примеры выглядели немного отличными от моего файла. Я заметил, что в файле программы PostgreSQL в дополнение к pg_hba.conf был также файл 20130529-150444-old-pg_hba.conf, который намного больше напоминал примеры, которые я нашел в Интернете. Этот файл имеет несколько строк комментариев до этих последних нескольких строк:
Я надеялся, что это был оригинальный файл pg_hba.conf, и если я заменил новый файл содержимым старого, postgres начнут работать снова. Нет такой удачи. Я надеялся, что в файле pg_log будет зарегистрировано больше файлов ошибок, чтобы узнать, исчезла ли ранее заявленная ошибка или что-то изменилось, но больше файлов не было зарегистрировано.
Я искал онлайн-службу в течение нескольких дней, и ничего, что я нашел, не сработало. Извините за такой длинный вопрос, но я хотел быть основательным и включить всю соответствующую информацию. Я был бы признателен, если бы кто-нибудь мог пролить свет на эту проблему или предложить предложения.
qaru.site
Не запускается служба PostgreSQL с базами данных 1С
Дата публикации: 06.12.2016 20:51
Иногда случается так, что пропадет электричество или неправильно выключен сервер, компьютер и результат -> "Не запускается служба PostgreSQL". А восстановить базы, особенно 1С Бухгалтерия, нужно "Кровь из носу".
Есть милион всяких статей, эти статьи пишут "Компьютерные гении" и нет статей написанных нормальным доступным языком, которые бы на картинках и дословно говорили как и что делать!
Если не запускается служба PostgreSQL самое просто это сбросить ЛОГ.
Как это сделать?
- Щелкаем правой кнопкой мыши по кнопке пуск и запускаем командную строку (не администратор).
- Заходим в папку "bin", у меня она находиться по слудющему пути C:\ProgramFiles\PostgreSQL\9.4.2-1.1C\bin, находим и перетащим pg_resetxlog.exe в командную строку дописав в начале созданной строки "CD" это нужно для того что бы перейти в нужную дерикторию ПРИМЕР-C:\Users\Sunrise01>CD "C:\Program Files\PostgreSQL\9.4.2-1.1C\bin" жмем ENTER
- Затем нужно ввести команду pg_resetxlog.exe –f "C:\Program Files\PostgreSQL\9.4.2-1.1C\data" , где C:\Program Files\PostgreSQL\9.4.2-1.1C\data в каждой операционке свой, этот путь можно посмотреть в самой службе (Администрирование->Службы->находим нашу "PostgreSQL Database Server 9.4.2-1.1C(x64)"->Открываем свойства данной службы):
- После очистки Лога запустите Службу.
- Затем сделайте резервную копию базы данных 1С, загрузите в файловый вариант и протестируйте её на наличие ошибок.
Надеюсь, что данная статься облегчит жизнь простым пользователям 1С.
Дополнительная информация.
Комментариев пока нет
Пожалуйста, авторизуйтесь, чтобы оставить комментарий.
Если Вы уже зарегистрированы на нашем сайте, но забыли пароль или Вам не пришло письмо подтверждения, воспользуйтесь формой восстановления пароля.
Восстановить парольВнимание! Для корректной работы у Вас в браузере должна быть включена поддержка cookie. В случае если по каким-либо техническим причинам передача и хранение cookie у Вас не поддерживается, вход в систему будет недоступен.
b4bgroup.ru
Почему не запускается postgres 9.6? — Toster.ru
Бывает что после отключение питания на Linux серверах с 1С вообще ничего не запускается. База postgres поломана и кэш 1С тоже. Вот шаги как заново всё привести в рабочее состояние.1. Запускаем postgres в сингл моде от пользователя postgres чтобы его не убил systemd по таймауту
root@1cserver:~# su postgres postgres@1cserver:~$ /usr/lib/postgresql/9.6/bin/postgres --single -c config_file=/etc/postgresql/9.6/main/postgresql.conf -D /var/lib/postgresql/9.6/main -P -d 1 2018-09-07 09:23:27.289 MSK [3421] DEBUG: запись о контрольной точке по смещению 23/36889418 2018-09-07 09:23:27.294 MSK [3421] DEBUG: redo record is at 23/3674B6A8; shutdown FALSE 2018-09-07 09:23:27.294 MSK [3421] DEBUG: next transaction ID: 0:18537840; next OID: 13492030 2018-09-07 09:23:27.294 MSK [3421] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0 2018-09-07 09:23:27.294 MSK [3421] DEBUG: oldest unfrozen transaction ID: 545, in database 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: oldest MultiXactId: 1, in database 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: commit timestamp Xid oldest/newest: 0/0 2018-09-07 09:23:27.294 MSK [3421] DEBUG: предел наложения ID транзакций равен 2147484192, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: предел наложения MultiXactId равен 2147483648, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.294 MSK [3421] DEBUG: starting up replication slots 2018-09-07 09:23:27.294 MSK [3421] LOG: система БД была остановлена нештатно; производится автоматическое восстановление 2018-09-07 09:23:27.298 MSK [3421] DEBUG: resetting unlogged relations: cleanup 1 init 0 2018-09-07 09:23:27.507 MSK [3421] LOG: запись REDO начинается со смещения 23/3674B6A8 2018-09-07 09:23:27.515 MSK [3421] LOG: invalid record length at 23/368B5C50: wanted 24, got 0 2018-09-07 09:23:27.515 MSK [3421] LOG: записи REDO обработаны до смещения 23/368B5C28 2018-09-07 09:23:27.515 MSK [3421] LOG: последняя завершённая транзакция была выполнена в 2018-09-06 20:47:59.49413+03 2018-09-07 09:23:27.515 MSK [3421] DEBUG: resetting unlogged relations: cleanup 0 init 1 2018-09-07 09:23:27.941 MSK [3421] DEBUG: performing replication slot checkpoint 2018-09-07 09:23:27.985 MSK [3421] DEBUG: предел наложения MultiXactId равен 2147483648, источник ограничения - база данных с OID 1 2018-09-07 09:23:27.985 MSK [3421] DEBUG: Граница членов мультитранзакции сейчас: 4294914944 (при старейшей мультитранзакции 1) PostgreSQL stand-alone backend 9.6.8 backend> После можно остановить postgres с нормальным кодом завершения и запустить в нормальном режимеroot@1cserver:/home/usr1cv8# kill -15 #ваш_пид_процесса root@1cserver:/home/usr1cv8# /etc/init.d/postgresql start [ ok ] Starting postgresql (via systemctl): postgresql.service.2. Останавливаем непригодный 1С и чистим его кэш и конфигурациооные файлы и запускаем заново
root@1cserver:~# /etc/init.d/srv1cv83 stop root@1cserver:~# rm -rf /home/usr1cv8/.1cv8 root@1cserver:~# /etc/init.d/srv1cv83 start3. Запускаем RAS и добавляем базы которые были у нас на сервере 1С
root@1cserver:~# /opt/1C/v8.3/x86_64/ras --daemon cluster root@1cserver:~# /opt/1C/v8.3/x86_64/rac cluster list cluster : 583eba18-b263-11e8-ed9e-309c239dab48 host : 1cserver port : 1541 name : "Локальный кластер" expiration-timeout : 0 lifetime-limit : 0 max-memory-size : 0 max-memory-time-limit : 0 security-level : 0 session-fault-tolerance-level : 0 load-balancing-mode : performance errors-count-threshold : 0 kill-problem-processes : 0 root@1cserver:~# /opt/1C/v8.3/x86_64/rac infobase create --cluster=583eba18-b263-11e8-ed9e-309c239dab48 --name=our_1c_db --dbms=PostgreSQL --db-server=1cserver --db-name=our_1c_db --locale=ru --db-user=postgres --db-pwd=our_postgres_db_password и так далее для каждой базы 1С что были на сервереРадуемся жизни :)
toster.ru
PostgreSQL служба не запускается #800699
Добрый день. Такая проблема. Изменил настройки postgresql.conf на рекомендуемые с итс и теперь не получается запустить службу PostgreSQL. Версия постгре 9.4.2-1.1Cx64. Вин сервер 2012 Ошибка: Служба PostgreSQL на "Локальный компьютер" была запущена и затем остановлена. Некоторые службы автоматически останавливаются, если они не используются другими службами. Подскажите что делать?
не может такого быть. ПГ работает как часы
Хотя нет, это только на линуксе
верните настройки .
вернул, всё равно так
переустановить чтоль постгре
а порты не заняты?
а как проверить
была как-то проблема с перезапуском службы. Во время отключения процессы продолжали висеть. Надо были либо руками убить процессы или рестартнуть систему
Так я рестартнул - всё равно
Вот в логе последнем в pg_log 2017-07-07 11:29:10 AZST LOG: database system was shut down at 2017-07-07 11:29:09 AZST 2017-07-07 11:29:10 AZST LOG: database system is ready to accept connections 2017-07-07 11:29:10 AZST LOG: autovacuum launcher started 2017-07-07 13:12:04 AZST LOG: received fast shutdown request 2017-07-07 13:12:04 AZST LOG: aborting any active transactions 2017-07-07 13:12:04 AZST LOG: autovacuum launcher shutting down 2017-07-07 13:12:04 AZST LOG: shutting down 2017-07-07 13:12:04 AZST LOG: database system is shut down
при новых запусках не пишет ничего в логах
а что с ним запускать-то, по адресу чтоль?
нет среди запущенных постгре
а порты не заняты его?
ну он бы тогда наверное на другое ругался, а ни на то, что служба запущена, а зетем остановлена
Говорят это проблема с правами. От чьего имени стартуешь?
с правами админа
попробуй local system
это где прописать, в самой службе? Там написано, кстати, в закладке "Вход в систему" заходить с учётки USR1CV8
И это ты называешь админские права?
мне кажется у этого пользователя нет прав на каталог с бд
это в самой службе в свойствах. В постгрешке же надо под своей учёткой запускать службу
блин, вообще не пойму что делать и почему упало и как восстанавливать. Беда.
как там лустин говорил, нет pg админа - нехер пытаться
локал систем уже пробовал?
а как, я не понял чем это поможет если у юзера есть права на папку
ну что значит нехрен пыпаться, если базы постоянно падают с нехваткой памяти.
Если ты так вопросы решаешь, то тебе лучше просто удалить это ПГ
с правами админа PG не запустится, куда учетка postgres делась?
открой диспечер задач, и прибей все зависшие процессы postgre
в самой службе постгре указан запуск от имени USR1CV8, у которого есть доступ к папке с файлами постгре и базами
нету их - я сервак перезапускал даже
укажи в службе самого крутого пользователя по правам, потом открой hd_pga.conf и добавь там host all all 192.168.0.0/24 trust
Там мало доступа, учетка, от которой стартует служба postgre НЕ ДОЛЖНА быть в группе Администраторов, и должна быть ВЛАДЕЛЬЦЕМ некоторых каталогов, например папки с базами. Без этого служба будет останавливаться.
не может такого быть, чтоб добавление в админы убивало службу
попробовал дать доступ, разницы никакой
удалил вообще конф и стала запускаться служба...
но настройки-то нужны какие-то
но база всё равно не доступна...
типовой конф подложи
где б его взять
установи postgres на другой машине
так, я переформировал postgresql.conf, служба запустилась, базы подрубились. Я попробовал разобраться в каком именно месте конфа была ошибка - оказалось, что на строке по умолчанию она на 1 и закомменчена. Если её хотя бы раскомментить - служба уже не запускается
а эта строка есть в советах по настройке постгре вот тут:
Это проблемы чисто ПГ под винду
Вдогонку вопрос. Надо ли
набрёл на советы по его отключению при ошибках с нехваткой памяти
ты понимаешь что такое мердж джойн?
смутно. Я так понимаю, что нужно для планировщика. Создаёт 2 ряда, потом их соединяет и работает уже с соединениями. В итоге, работа быстрее, но памяти на соединение жрёт больше.
прочитал описание, вроде как штука хорошая в плане оптимизации огромных запросов. Надо будет потестить разницу как-нибудь.
Этому очень много лет. "Unfortunately, effective_io_concurrency is not supported on Windows. It works on Linux and UNIXes, but must be 1 on Windows"
Просто добавить памяти.
16 гигов - куда ещё. Базы-то мизерные, гигов по 5.
или речь о настройке work_mem?
Весьма доступно о том, для чего не помешает больше памяти.
просто откиньтесь на спинку стула.
в следующий раз смотри журнал событий виндовс - там всё что надо написано
Tags: 1С 8
avprog.ru
postgresql - Postgres не запускается после удаления файлов pg_xlog
Использование Debian Wheezy, Postgresql 9.3
Моя база данных опустилась, потому что раздел, в котором он хранит файлы WAL, заполнился. Итак, я удалил все внутри ./pg_xlog/, потому что я не знал, что они были (да, невероятно глупо от меня). Теперь служба Postgres не запустится, хотя проблема, согласно syslog:
00000: could not open tablespace directory "pg_tblspc/16386/PG_9.3_201306121": File or directory not found LOCAL: RelationCacheInitFileRemoveInDir, relcache.c:4895 00000: Primary checkpoint record is invalid LOCAL: ReadCheckpointRecord, xlog.c:6543 00000: Secondary checkpoint record is invalid LOCAL: ReadCheckpointRecord, xlog.c:6547 PANIC: XX000: could not locate a valid checkpoint record LOCAL: StartupXLOG, xlog.c:5228Я не совсем уверен, проблема в том, что он не может найти правильный pg_tblspc или полное отсутствие файлов контрольных точек WAL. Фактический путь к месту хранения баз данных - /dados/PG_9.3_201306121. Что я могу сделать, чтобы запустить сервис снова?
EDIT1: Хорошо, мне удалось вернуть эту новость в Интернете. Некоторые базы данных были повреждены. Мне удалось выполнить DROPDB два из них (они даже не могли подключиться к ним без принудительного перезапуска службы). Я попытался сделать это с другой, получившей повреждение, но ошибка снова была связана с xlog. Я пробовал сделать над ним чистое восстановление, но восстановление было неполным. Затем я создал новую базу данных и попытался восстановить старую резервную копию этой базы данных. Это также было неполным.
Теперь я не могу отказаться от каких-либо баз данных и не создавать новые, я всегда получаю ошибку xlog flush request not satisfied. Я попытался запустить pg_resetxlog, но, похоже, ничего не сделал. Другое, что показывает ошибка: cannot write to block 1 of pg_tblspc/16385/PG_9.3_201306121/36596452/11773, write error may be permanent.
EDIT2: Часть проблемы выше была с этим 11773 файлом. Я переименовал его в 11773.corrupt, и теперь база данных позволяет мне создавать и снова отбрасывать.
qaru.site
