Хмм... откуда такое в дампе (в норме, там вообще INSERT-ов нет)?
Как Вы его сделали и т.п.?
Какая это полная версия PostgreSQL?

Т.е. Вы можете потом в psql подключиться и на любой запрос получите вот это?

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

именно

Так сделайте \errverbose и посмотрите, откуда она выбрасывается.

> . Да и не верю я как-то в это уже, т.к. дамп в sql формате.

Да любой дамп — это SQL, по сути.
Кстати, "битость" дампов, по идее, может быть только в том, что при декомпрессии получается какая-то ерунда, если файл побился почему-то. Но это можно проверить, попытавшись его развернуть в SQL.

pg 12.3
db1=# select 1;
ERROR:  invalid memory alloc request size 12776525720924364720
db1=# \errverbose
ERROR:  XX000: invalid memory alloc request size 12776525720924364720
LOCATION:  palloc, mcxt.c:934

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

про  \errverbose не знал, спасибо, интересно.

Должно быть, да. Да и вообще, разворачивание дампа — просто выполнение последовательности SQL statements, и обязано к таким эффектам не приводить. :(

Жёстко. А если к любой другой базе подключиться?
А в логах PostgreSQL ошибок нет (в смысле... их там наверняка куча, найти бы первые, связанные с этой проблемой)?
А этот кластер возможно перезапустить, на всякий случай?

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

уже пробовал полностью сносить кластер, инициализировать снова и снова разворачивать базу - не помогло.

А точно у Вас проблем с "железом" нет? Потому что иначе Вы почти наверняка наткнулись на bug PostgreSQL.

По поводу железа не могу точно сказать. Именно поэтому и стал сюда писать по поводу возможной природы ошибки)

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

А если на другом сервере (где установлен PostgreSQL той же версии) попробовать?

> По поводу железа не могу точно сказать.

Вот я бы сначала в этом направлении поискал, т.к. поведение какое-то совсем странное (не очень похоже на bug).

Я, кстати, как-то видел что-то подобное — в том случае, насколько я помню, RAM и диски оказались исправными, а "вылетело" что-то на motherboard, видимо (там не стали копаться / разбираться) — стали сыпаться "invalid memory alloc request size",  "левые" ошибки при запросах, потом ошибки контрольных сумм... очень странно это выглядело, в общем. ;)
(Я так подумал, что какие-то биты изредка "бились" при передаче по какой-то шине.)

есть еще один вопросик, относящейся к другой проблеме и другому серверу) он более общий.
Есть ли какая-то методика нахождения причины регулярного падения базы? Нашли закономерность при падении, но не понимаю, как или чем копнуть глубже. Может есть какие-то статьи на примете полезные  у вас?
Проблема c сигналом segfault 11.

Опять-таки, начните с логов PostgreSQL.
А какая закономерность-то?