Melkij

CPU(s):                          256
On-line CPU(s) list:             0-255
Thread(s) per core:              2
Core(s) per socket:              64
Socket(s):                       2

Я не понял проблематику ситуации. 40 ядер, несколько сотен гигов RAM да пара десятков дисков - средняя железка, какие там у вас специфические проблемы такие? 40 ядер нынче не проблема даже одним сокетом получить.

Что касается памяти тут отдельная история, поступила жалоба, что U-DIMMы работают только при полной сборке (все 16), либо подключенные последовательно (с1 по 4 место например), но подключая в 1,3,7,12(например) места некоторые планки не определяются, либо сервер работает не корректно (не запускается, не стартует).

См. документацию к материнке. Там будет описано, в каком порядке необходимо заполнять слоты. Да, это стандартное требование JEDEC для DIMM'ов, что серверных, что десктопных. Технически связано с терминаторами. Затем, после требований стандарта, идёт логика как не повесить всю имеющуюся память на один и тот же канал памяти одного и того же CPU. NUMA всё-таки.
Вы правда занимаетесь серверами?

Сначала внимательно посмотрите на свой триггер, не пускаете ли вы его в бесконечную рекурсию. Нет, postgresql не будет вам мешать делать бесконечно-рекурсивный триггер и никак не будет препятствовать его выполнению до тех пор пока это будет возможно физически. И вот тут stack depth limit обычно и заканчивается первым.

Это так называемый fake raid. Удивительная поделка, объединяющая недостатки одновременно аппаратного и программного рейда, но не обладающая никакими из их достоинств.
Использовать можно только если скучно и хочется приключений.

Не забудьте настроить бекапы. Рейды с избыточностью данных это про снижение простоя, а не замена бекапам.

pvresize. Затем lvresize с resize2fs или lvcreate дальнейшие или ещё чего, смотря зачем увеличивали.

Единственный смысл добавления всё новых проводов от блока питания к материнской плате помимо 20-контактного коннектора ATX из 1995 года - уменьшение силы тока, протекающего по наиболее загруженным проводам и контактам разъёмов.

Как простое следствие этого - нет никакого физического смысла в использовании разветвителя. Это никак не уменьшит силу тока, протекающего по кабелю от блока питания. Позволит обмануть плату, если она требует чтобы оба коннектора были подключены, но это именно обман, а должны быть раздельные комплекты проводов от блока питания.

internals 64 битные
heap 32 битные

Если вы хотите чтобы ни один крупный проект не стал обновляться на такую новую версию - без проблем, поменять формат страницы heap не так уж сложно. Почему после принятия такого патча никто не станет обновляться? Потому что вместе со сменой формата страницы вы напрочь сломаете in-place pg_upgrade и вынудите обновляться только через dump+restore. Удачи это сделать на 10тб базе за обычные для pg_upgrade 5-10 минут даунтайма. А если у вас крошечная база которую можно за 10 минут обновить дампом - то вам и 64-битные xid банально не нужны и не важны.
Если интересно поподробнее, подождите запись вот этого свежего доклада

Для начала, в postgresql нет типа данных string. (а если это самодельный тип, что postgresql сделать тоже позволяет, то смотреть надо как он реализован у вас)

Для текстовых данных в postgresql есть:
- text. Просто text, без специфических ограничений на содержимое
- varchar - это всё тот же самый text. К varchar можно добавить указание ограничения максимальной длины хранимого текста в символах. Почему это отдельный тип данных? Потому что такого требование стандарта SQL
- char - фиксированный длины (в символах! в байтах они всё равно динамической длины получатся для того же utf8). Смысла его использовать в postgresql, как вы сами процитировали документацию, нет. Зачем он нужен? Потому что описан в стандарте.

В отличии от, например, mysql, для postgresql нет ничего особого в значении 255. Если в определении таблицы видно такое ограничение на 255 символов - обычно это означает именно "никто не обдумывал цель такого ограничения для этого поля, просто какое-то число"

Говоря о выборе между text или varchar(N) - varchar(N) с разумным для этих данных N предпочтительнее для коротких строк, потому что не даст записать 10мб туда где должно быть, например, не более 64 символов (это не совсем шутка, случай из практики). А по ошибке в месте записи дебажить логику приложения куда как проще, чем искать потом откуда такое взялось.

Насколько я помню: https://github.com/php/php-src/blob/PHP-8.0/ext/pd...
Нужен mysqlnd для получения родных типов данных.

Power-up in standby (PUIS). Должен уметь контроллер дисков.

Почитайте вот этот топик: https://forum.ixbt.com/topic.cgi?id=11:44797 может быть найдёте что-то для себя полезное.

source читает указанный файл с начала и до конца, передаёт серверу как будто это SQL команды. Никакой дополнительной логики не предполагается.
https://dev.mysql.com/doc/refman/8.0/en/mysql-batc...

Эквивалент "mysql db_name < text_file"

Есть ощущение, что PgBouncer подготавливает выражение для ускорения работы при первом запуске, но после остановки выполнения где-то на середине и последующего запуска, PgBouncer все еще считает, что выражение должно остаться на сервере, а вот сервер уже так не думает.

Замените слово "PgBouncer" на "ваше приложение" и тогда получите относительно верное описание происходящего.

С практически 100% вероятностью у вас pgbouncer сконфигурирован в режиме transaction pool mode. А выполнение любого нового запроса в extended protocol (prepared statement) состоит из трёх вызовов:
- prepare
- bind
- execute
Нет ничего ошибочного в том, что pgbouncer сконфигурированный в режиме пула транзакций может направить каждое из этих 3 сообщений в разные коннекты базы. Это прямым текстом задокументированное ограничение пула транзакций. Итог закономерный, соответствующие процессы базы не понимают о чём речь и выражают удивление такими ошибками.

Отключите использование server-side prepared statements на приложении.