А не направите в какую сторону почитать или посмотреть сорцы как это устроено?

Увы, мне тоже для этого пришлось бы смотреть исходники. Я не знаю в какое точно место смотреть

За телефоном не удобно

Ох ну спасибо, покопаюсь сам тогда. Обнадеживает что может быть такой простой фикс

Это по опыту, происходить будет так

Я как себе представляю - malloc не удается, дальше процесс сворачивает манатки, дропает валы и уходит на отдых, а постмастер или кто-то там еще запускают уборку.

...и наверное именно потому оно работает, что sigkill нельзя обработать.

Приветствую. Подскажите пожалуйста, postgres достаточно умный, чтобы не вызывать функции во время агрегации на полях, по которым идет агрегация? Или надо в подзапрос выносить и отдельно функцию считать?

select label, some_expensive_function(label) from t group by label

Коллеги подскажите плиз почему бьет ошибку в запросе:  ALTER TABLE ebol_all ALTER COLUMN service_provider_unp TYPE integer USING service_provider_unp::integer;   Ошибка : ERROR:  invalid input syntax for integer: "CA0238683"

Читать релизнотесы (на самом деле не надо, надо доку: https://postgrespro.ru/docs/postgresql/11/kernel-resources ), ПГ не использует malloc, он использует mmap, начиная с 9.3.
У меня вообще серьёзные сомнения, что процесс при ошибке выделения памяти будет падать. Скорее всего, при недоступности нужного объёма ПГ будет работать по через диск и прочие временные файлы.
Хотя тут интересно было бы услышать разработчиков ПГ

explain как ни странно помог найти ответ

Только хотел посоветовать. :)

nested loop при условии join-а id = any(values) всегда остается nested loop ?
думаю, попробовать gin index или unnest-ить values

По-моему, там чётко написано, почему и зачем, разве нет?

Постгрес  использует 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. Ну или иметь достаточный СВАП.
Ну а самое правильное - не запускать такие процессы которые выжрают всю память:)

потому что у вас там не-числовые данные

так вот именно,что только числовые.Коллега от страху поставил character varying вот сейчас хочу исправить но что то не получается

ну база же явно в ошибке говорит, что — нет

так вот да и я себе уже не верю...пересматриваю уже 3 раз ..... понял,значит сейчас будут кардинальные действия....спасибо большое за ответ

Здравствуйте, как исключить эту проблему?