(как и с vm.overcommit_memory — про нее никто не знает и не трогает)

Причём тут потоки? Узлы плана запроса ограничиваются, каждый отдельно.

Нет. OOM kills — это именно что следствие неправильной настройки OS, в норме их не должно быть, чего бы там ни "хотел" PostgreSQL.

а что система будет делать если памяти не хватило и оом нельзя?

А шо оно, пока весь запрос не выполнит — память от промежуточной работы не освобождает?
Я просто в нутрях постргеса не разбираюсь — так, документации обчитался. Вдруг там и правда такая дичь.
Обычно когда я что-то долгое и пятиэтажное запускаю — я смотрю, как оно начинает в каталог (забыл, как называется) писать, а не память жрать. Постгрес вообще ведет себя очень воспитанно и лишней памяти не жрет.

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

Вернёт out of memory, процесс PostgreSQL "превратит" его в ошибку в запросе (OOM), этот запрос откатится (ну и без SAVEPOINT / exception handling — вся транзакция), и всё.
А вот OOM kill роняет весь instance postgres, что гораздо неприятнее, обычно.

ок спасибо большое)

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

Причём тут "дичь", если все эти узлы всё ещё нужны?
Например, если для merge join нужно отсортировать два источника rows, то до [конца] слияния нужно хранить отсортированные данные того и другого — вот уже может быть использовано 2x work_mem.
Ну и так далее.

Потому что памяти-то хватает (т.к. overcommit практически нет).

А что «далее»? Далее после мержа исходные строки освобождаются.

Подождите, Вы ту документацию читаете?
Вот эта часть:

It is possible to modify the kernel's behavior so that it will not “overcommit” memory. Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior. This is done by selecting strict overcommit mode via sysctl:

sysctl -w vm.overcommit_memory=2

or placing an equivalent entry in /etc/sysctl.conf. You might also wish to modify the related setting vm.overcommit_ratio. For details see the kernel documentation file https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.

Лучше сочетать то и другое. Кстати, .deb дистрибутив PGDG уже содержит oom_score_adj, насколько я помню.

Но merge / hash / sort в плане может быть далеко не один.
Поэтому и чёткого предела того, сколько памяти будет использовано, нет.

It is possible to modify the kernel's behavior so that it will not “overcommit” memory. Although this setting will not prevent the OOM killer from being invoked altogether, it will lower the chances significantly and will therefore lead to more robust system behavior. This is done by selecting strict overcommit mode via sysctl:

sysctl -w vm.overcommit_memory=2

or placing an equivalent entry in /etc/sysctl.conf. You might also wish to modify the related setting vm.overcommit_ratio. For details see the kernel documentation file https://www.kernel.org/doc/Documentation/vm/overcommit-accounting.

ну это не исключает oom, а уменьшает его вероятность, да, может значительно уменьшает, в любом случае помогли, спасибо, всегда надо читать доку)

протестируем

На практике — уменьшает приблизительно до нуля. ;)
А дальше уже можно заниматься tuning собственно PostgreSQL.

а другие какие-то настройки ядра посоветуете? shmall,shmax вот на хабре пишут в новых версиях постгреса смысла не имеет

overcommit_ratio глянте, если меняете политику выделения памяти

Так там в этом разделе есть и ещё — те же huge pages.

> в новых версиях постгреса смысла не имеет

Да, это практически так (со стандартными настройками в большинстве дистрибутивов linux нужны тысячи соединений (max_connections), чтобы вообще начать про это думать, если я правильно помню).