Дмитрий Кинаш

1) Или сервер не запущен (проверять в службах или в процессах)
2) Или запущен на нестандартном порту
3) Или запущен не на локалхосту.

Теоретически еще может быть файрвол, который блокирует 5434, но маловероятно.

Вы пытаетесь развернуть базу с помощью psql как будто вам дали бэкап выполненный с помощью pg_dump.

Это не так! DT - это внутренний формат бэкапирования баз 1С. Развернуть можно если открыть конфигуратор и выбрать в меню "Загрузить информационную базу". Или с помощью командной строки по ключику /RestoreIB

Вопрос очень старый, но он все еще проиндексирован и при этом не имеет ответа. Поэтому включаем режим "экстрасенса" :)

есть xml файл на 2млн. строк, по сути база 1C

Штатно базы 1С не выгружаются в XML. В XML можно выгрузить только конфигурацию или ее элементы. База штатно выгружается в архив *.dt
Следовательно у автора вопроса есть выгрузка либо с помощью обработки "Обмен данными XML", которая позволяет хоть все данные выгрузить в XML-формате для загрузки в идентичную конфигурацию. Либо выгрузка с помощью конфигурации "Конвертация данных 2.0/1", которая выгружает указанные данные в XML-формате, который описан в этой служебной конфигурации.

Нужно как-то перенести её в SQL или что-то подобное.

Вероятно упоминается продукт MsSQL, так как SQL - это язык запросов. Практически все современные СУБД поддерживают импорт данных из файлов XML. Вот дока по MsSQL.

Подумываю регнуть облачное хранилище для 1С, развернуть это всё дело там и как нибудь экспортировать в нужном формате.

Если есть доступ к 1С, то проще сразу выгрузить в нужно формате. Второй вариант - грузить сырые данные в новую базу из XML файлов, а далее уже на месте редактировать структуру таблиц и чистить "мусор". Как вариант, можно SELECTами сделать выгрузку только нужной информации в файлы для последующей загрузки в финальной базе.

Если спасли каталог с базами и логами, то вам повезло. Устанавливайте на новом сервере Postgres, вместо новосозданного каталога с данными подсовывайте свой и запускайте службу.

У меня была чем-то похожая ситуация. На сервере стало заканчиваться место. Мы добавили диск, скопировали все данные постгреса на новый раздел, подправили пути в конфигах и после запуска все заработало на ура - не могу вспомнить что бы какие-то сложности вылезли.

P.S. То что вы не делали бекапы - это плохо. Сейчас бы не мучались, а просто развернулись с архивчика.

Подобных проблем не было (было много других, которые намного хуже — вы даже не подозреваете сколько в линуксовом сервере 1С подводных камней).

Давайте посмотрим с точки зрения здравого смысла.

1) В конфигураторе запросы не выполняются — там происходит только конфигурирование и администрирование. Запросы вы выполняли скорее всего в тонком или толстом клиенте, который подключен к серверу. Поскольку вы упомянули конфигуратор, то склоняюсь к выводу, что речь идет именно о толстом клиенте с подключением к серверу в локальной сети по TCP.

2) Веб-сервисы у вас подняты на Apache и обслуживаются с помощью апачевского модуля, который подобно тонкому/толстому клиенту подключается к серверу 1С по TCP, получает от сервера данные, а далее возвращает ответ клиенту по HTTP(S).

На поверхности лежит вывод, что в обоих случаях сервер отрабатывает с одинаковой скоростью (если в моменты тестирования нагрузка был идентичной), а вот на обслуживание HTTP(s) запросов/ответов веб-сервером тратятся ваши лишние 50 секунд. Проверяйте в этом направлении — на 70% уверен, что или ваш Apache настроен через ж, или на нем кроме опубликованной 1С крутятся другие нагруженные приложения и время на 1С-вский модуль выделяется по остаточному принципу.

Еще вариант, что вы не все рассказали. Моя вторая версия, что данные запроса в толстом клиенте вы получаете единой выборкой, а вот веб-сервис вы делаете не на единичный запрос, а на каждый элемент выборки заново устанавливаете ws-соединение. При таком подходе даже на выделенном сервере скорость веб-сервисов в случае больших данных будет в сотни и тысячи раз медленнее чем работа в 1С-вских клиентах.

Для практически применимого ответа слишком мало информации.

Во-первых, неизвестна платформа вашей 1С-базы и её конфигурация.
Во-вторых, о второй учетной базе с данными в PostgreSQL вообще никакой информации нет — умеет ли работать с веб-сервисами, с xml-файлами, с Excel или просто с текстовыми файлами в конце-концов? А может это у вас еще одна 1С-кая конфигурация только на PostgreSQL?

Не удивительно, что вы ничего не нагуглили :)