Постгрес  использует malloc внутри бэкенда для "рабочей" памяти при обработке запроса.
Если malloc  возвращает NULL, то просто репортится ошибка:

src/backend/utils/mmgr/mcxt.c:
 if (unlikely(ret == NULL))
 {
   MemoryContextStats(TopMemoryContext);
   ereport(ERROR,
       (errcode(ERRCODE_OUT_OF_MEMORY),
        errmsg("out of memory"),
        errdetail("Failed on request of size %zu in memory context \"%s\".",
              size, context->name)));
 }


После чего абортируется текущая транзакция. И сам постгрес и даже  бэкенд продолдают работу.
Размер временной памяти задаётся work_mem параметром, но это не жётское ограничение но "пожелание" посгресу не выходить за эту границу.

Но недостаток памяти в системе может сказаться не только на malloc-е.
И для shared memory может не хватить физической памяти (особенно если выключен свап)
Тогда придёт страшный OOM killer и прибьёт первого попавшегося. Это с большой вероятностью приведёт к перезагрузке всего постгреса.

Справиться с этим на уровне посгреса никак нельзя. Можно пытаться ограничить аппетиты бэкендов и других процессов с помощью квот или  cgroups. Ну или иметь достаточный СВАП.
Ну а самое правильное - не запускать такие процессы которые выжрают всю память:)

Никогда этого не пойму:

test=# select now(), now()::timestamp at time zone 'Europe/Moscow', now()::timestamptz at time zone 'Europe/Moscow';
             now              |           timezone            |          timezone
-------------------------------+-------------------------------+----------------------------
2020-05-28 09:53:49.303624+00 | 2020-05-28 06:53:49.303624+00 | 2020-05-28 12:53:49.303624
(1 row)

test=#

Хотел сделать pg_upgrade, может кто знает как это пофиксить?

постгис небось?)

Тут всё очевидно, вообще-то.
И кстати, если нужно "всерьёз" работать с временными отметками —  пока Вы этого не поймёте, лучше даже не начинать, IMNSHO. ;)

Всем привет, возник вопрос по таймзонам.
На сервере стоит таймзона UTC, даты хранятся в обычном timestamp,
когда я пишу select created_at at time zone 'Europe/Moscow' я ожидаю увидеть сохранённое время +3 часа, но получаю -3.
Почему это так работает? Как получать дату и время скорректированные под таймзону текущего юзера (она известна, хранится в виде строки)

Спасибо, уже начал не начинать.

Да Вы не принимайте на свой счёт, если что — просто в этой теме и так немало мороки (если данные "со всего света").
И это даже при условии "владения инструментом", т.е. понимания того, как timestamp-ы работают в PostgreSQL.

У меня, например, есть подозрение, что в некоторых особо "удачных" ситуациях работы с датой/временем, с которыми мне приходилось сталкиваться, ошиблись бы вообще все присутствующие в этом чате (потому очень долбанутые законы (связанные с time zones) бывают во всяких неведомых странах) . ;)

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

https://postgrespro.ru/docs/postgresql/9.6/pgupgrade

ну, тут 5й пункт говорит о том что нужно проверить что в новой установке есть все расширения и пр. что были в старом. Походу этот пункт пропущен при подготовке.
Какой именно postgis и как с ним обращаться при pg_upgrade к сожалению не подскажу - нет опыта. Но палюбому гуглить начать с этого.

> На сервере стоит таймзона UTC

На каком сервере? В PostgreSQL не существует такой вещи, как "серверная time zone", есть только default для новых сессий.

> , даты хранятся в обычном timestamp,

И это уже fail. Более того, если они там (почему-то) не только в UTC — это уже не исправишь.
Правильный тип для хранения моментов времени в прошлом — только timestamtptz.
Вообще, см. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Date.2FTime_storage