он пишет что я неавторизирован

так значит так видимо и есть, авторизуйтесь, какие проблемы

вот в чем

зайди в трей, там есть postgres, правой кнопкой и копируй ссылку

починил через реестр могу дать ролик в помощь

давай)

https://www.youtube.com/watch?v=YabjU7eyV94&ab_channel=FelixCastro вот только на испанском или на каком-то языке но он все показывает если я понял то ты тем более поймешь

я далеко не "тем более", спасибо)

Добрый день. Имеются несколько глобальных проблем, которые хотелось бы решить. Но не знаю даже, с чего необходимо начать анализ.
БД: PostgreSQL 13
Конфигурация машины: 12 vCPUs, RAM 64GB, Storage 2TB (об этом чуть ниже)
Конфигурация базы: стандартные настройки при инициализации базы через Google Cloud SQL (но можно позже отобразить все настройки), за  исключением параметра max_connections, который равен 3,000.

Проблема 1.
Непонятно что занимает Storage машины базы. Под непонятно что я на самом деле подразумеваю непонятно что. Ибо на данный момент с помощью команды SELECT pg_size_pretty( pg_database_size('DB NAME') ); выводит размер базы 51 GB, и это на самом деле так и есть (пробежался ещё по размеру каждой из таблиц), но через панель управления базой в Google Cloud отображает занятую память 1.5 TB из 2 TB, и это значение увеличивается на несколько гигов чуть ли не каждую минуту. Как понять, что это вообще такое? Из-за чего это может быть? Кэш, ошибки, логи, без понятия.

Проблема 2.
Работа с PostgreSQL впервые, но таких проблем при работе с другими базами не встречал.  Обычная стандартная установка базы и дальше самые обычные запросы для только вставки и проверки данных на существование в таблице (никаких удалений и обновлений на данный момент нет). И тем не менее, только с PostgreSQL наблюдаются проблемы: странное (для меня) использование RAM, что приводит к волнам на графиках (см. скриншот ниже). Когда память находится в пике, работа с базой невозможна. В Datagrip пишет: FATAL: the database system is in recovery mode, воркеры в это время в ожидании возобновления работы базы, поэтому обработка чего-либо становится невозможной.
Почему так происходит?

2 - это ООМ

max_connections 3k - для 12 ядер это овердофига. Не надо 3к коннектов делать, нужен пул коннектов.

1 - это скорее всего копится WAL, надо проверить архивацию, слоты репликации, долгие транзакции и двухфазные транзакции.

ООМ - скорее всего следствие 3к коннектов, если что

на 64Гб - лимит подключений для Cloud SQL - не более 800

Ну и правильно. У нас тоже 200 на процессорное ядро.

У гугла нормально со слотами и вал. Это скорее tmp файлы даже, но т.к. доступа нет внутрь - оптимизируйте настройки и откройте кейс

временные файлы будет видно в логах

Но накопить 2Тб временных файлов с ООМ раз в полчаса - почти невозможно.