Postgresql 10.4 с проблемой pgadmin 4 v3.0 - ошибка инициализации инструментов запроса для пользователя Windows 10 x64

Такое же сообщение появляется при нажатии на меню «Инструмент запросов».

Если вы продолжаете повторять это действие снова и снова, вы в конечном итоге можете добраться до инструмента запросов. Иногда (редко) срабатывает. Вы можете порождать процессы, хотя, попробовав этот подход. Проверьте панель управления, чтобы увидеть / уничтожить процессы, порожденные при каждой попытке запуска инструмента запроса. Я не нашел другого способа получить доступ к инструменту запросов. Я также не могу вернуться к pgAdmin4 версии 2. В консоли инструментов разработчика браузера нет информации, и я не вижу никакой информации в журналах pgAdmin4, когда я нажимаю меню инструмента запроса. Как указано на другом форуме, использование меню File / Reset Layout может помочь решить эту проблему. Однако у меня был ограниченный успех в этом.

Я использую: pgAdmin4 version3. Windows 10 Профессиональная. PostgreSQL 9.3, 9.6 и 10. FireFox 60.0.1, Microsoft Edge 41.16299.402.0 и Google Chrome (последняя версия).

Как ответ от pgAdmin 4 v3.0 Query Tool Initialize Error предполагает, что вам нужно отредактировать файл config.py из вашего местоположения Windows. Мой выглядит так: "C: \ Program Files (x86) \ pgAdmin 4 \ v3 \ web", и там у вас есть строка с:

DEFAULT_SERVER = '127.0.0.1'

это должно быть изменено на

DEFAULT_SERVER = 'localhost'

Затем не забудьте перезапустить pgAdmin из панели задач. Я думаю, это связано с тем, что ваша база данных postgres при установке была установлена ​​как «localhost» вместо «127.0.0.1».

Надеюсь это поможет

ОБНОВЛЕНИЕ: я также обнаружил, что это решение не работает, когда вы используете брандмауэр.

Спасибо за ваше предложение. user3613316 Я выполнил ваши инструкции, это действительно то, что мне нужно запускать инструмент запросов снова и снова для входа в меню Инструмента запросов.

Иногда требуется более 15 или 20 раз этого действия, чтобы войти в меню «Инструмент запросов». Я использую сочетание клавиш Alt + Shift + Q, чтобы продолжить работу быстрее.

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

1. журналы веб-сервера
2. журналы postgresql
3. выходы консоли браузера

Если ваш веб-сервер (если вы не обращаетесь к порту pgadmin4 напрямую) проксирует правильный порт со всеми правильными параметрами. Я использую nginx, и он отлично работает с:

server
  {
    server_name db.serv1;
    listen 443 ssl http2;

    ssl_certificate /etc/letsencrypt/live/myserver.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myserver.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/myserver.com/fullchain.pem;

    location /
    {
      proxy_pass http://127.0.0.1:5050;
      proxy_http_version 1.1;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
    }
  }

Убедитесь, что для параметра X-Frame-Options не установлено значение «DENY». Иногда это устанавливается в браузерах для предотвращения кликджекинга. В противном случае он заблокирует фрейм, в котором открывается окно «Инструменты запроса». Вы можете проверить это с помощью «проверки» своих веб-инструментов или открыть вывод консоли для браузера.

Сообщение об ошибке, которое я получил, было где-то в строке «X-Frame-Options set to 'DENY'», а на странице браузера отображалось «FAILED TO CONNECT».

Если у вас есть различия в «localhost» и «127.0.0.1» или похожие типы различий между вашими настройками разрешений и параметрами подключения, это может создать конфликт. Убедитесь, что параметры подключения к серверу, указанные в pgadmin4, соответствуют параметрам подключения в pga_hba.conf (localhost не всегда совпадает с 127.0.0.1). Они должны быть точными, и это устранит различие между разрешениями и типом подключения.

Я обнаружил, что иногда при указании localhost вместо 127.0.0.1 этот localhost в некоторых случаях подключается через соединение сокета домена Unix, а не через tcp.

Были аналогичные проблемы с зависанием с последней версией pgAdmin 4-4.13; попробовал все предложения, но это не сработало. Откатился на 4-4,6, и все вернулось на круги своя. Потраченное время зря!